|
|
Posted by rf on 07/16/07 10:30
"Jim" <jimyt@yahoo.com> wrote in message
news:1184578259.619879.293680@k79g2000hse.googlegroups.com...
>> > If I could think of a way of doing it efficiently then I'd stick with
>> > db only, but I can't see how. For example, I have a table which
>> > represents the structure of the site, so to put it simply each record
>> > has an id and a parent id. To build say a left hand nav I may need to
>> > call 3 or 4 sql statements to get all the data I need which I'd like
>> > to avoid doing if possible.
>>
>> Premature optimization?
>
> Perhaps, but I'm still interested in the shared memory caching options
You already have one. Your operating system. Modern OSs (and many older
ones) are very very good at keeping a processes working set in memory. The
authors have spent many years fine tuning the caching algorithms. A cache
miss is very expensive (read many milliseconds). A cache hit is to be
ignored (microseconds).
<checks OS> Yep. Of the two gigabytes of physical memory present on this
computer the OS is currently allocating almost one gig to System Cache. In
there would be the working set of each program I have open (not windows,
programs), the working set of each process (yes, windows) I have open and
most likely the contents of the most recent files each process has opened.
In the case of my database server I would expect that most of the indexes
and much of the data that I have recently hit would be in the OS cache. All
this is over and above the virtual memory living behind my real memory,
which is much faster than any file other access.
Your server would be running far less processes than I am at the moment.
> as there's more than once instance where I believe caching of data
> would come in handy. At the moment I'm not seeing issues with with
> performance, however on accessing a page I may have 5 or 6 db
> statements accessing data which rarely changes (i.e. site structure,
> data dictionary)
So, those things will most likely be in the OS cache, if they come from a
database (after the first hit on your page, that is). If *you* re-cache them
in memory then you are defeating the OS or the database cache, since your
memory cache will use up memory that they may have been able to use. And,
I'll bet, they are better at cache algorithms than you, or I, are :-)
> and it feels like I'm making the db work un-
> necessarily when the data could be cached.
Cross purposes. The db is working from cached data. Why layer another
caching system over the top of that?
> I need for the cms to be
> able to scale well
Think about all the other CMS's around. They all use a database. Then think
about the obviously database driven web sites out there. CNN, ebay and, most
to the point, Google. Do you really think they have put lots of effort into
building a turnkey memory cache? Nope. They rely on the technologies that
lie underneath the sql call. They rely on the database manager to perform
properly (ie, cache where it can, and should), which relies on the operating
system to perform properly (ie, cache where it can), which relies on the
hardware to perform properly (ie, to cache where it can and yes, modern disk
drives do cache, they even do read ahead, anticipating that if you have just
read this bit you will probably read what follows pretty soon).
> and I feel that ignoring caching would be a
> mistake.
Developing a cache to lie above all the other technology that is already
there would IMHO be the mistake. Better to simply add one more index in the
right place to your database, so your database manager can use the (cached)
index to better access your data. Or compress that 200K image you have down
to the 20K it should be.
Finally, what about all the other things that happen during a page access.
How many PHP files make up the page? (you do use include don't you?) How
many (correctly compressed) images are there? The CSS files? Javascript? And
where do these files live, after the first hit on your site? In the OS cache
:-)
Premature optmization.
Phew, it's now time for a quiet beer ;-)
--
Richard.
Navigation:
[Reply to this message]
|