Posted by FrobinRobin on 07/16/07 11:19

On Jul 16, 11:30 am, "rf" <r...@invalid.com> wrote:
> "Jim" <ji...@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.

i am developing a system which relies heavily on multiple includes()
functions and has lots of sql calls/data.. so i saved my sql results
to a session array (so it only calls the results once and updates it
only when needed).. i thought all the sql would slow the page down a
lot (especially as I'm on a shared hosting server) but to my surprise
PHP is really really quick - i'm not even up to half a second yet :)

[Back to original message]