|
|
Posted by Jim on 07/16/07 11:21
> > 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 :-)
I understand what you're saying but when you consider that each time I
display a nav I need to execute a recursive function which may result
in many calls to the database then I struggle to believe that it'll be
anywhere near as quick as retrieving an array from shared memory, even
if the entire database if cached....I'll have to perform some tests.
> > 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?
Because there's a fair amount of php code executed to build the multi-
dimensional arrays that represent the site structure and data
dictionary. It would save the execution of this code every time.
I think I need to run some tests and see what happens. I'll give
eAccelerator a go for now.
Cheers,
Jim.
> > 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.
Navigation:
[Reply to this message]
|