Re: [PHP] Aggressive PHP Smart Caching
- From: quickshiftin@xxxxxxxxx ("Nathan Nobbe")
- Date: Thu, 23 Aug 2007 23:50:22 -0400
Alexander,
i have begun to experiment w/ your caching tool.
i wonder if you would mind providing some feedback..
firstly i noticed a call to ob_start(),
ob_start('cacheSave');
which references the method defined beneath the initial bit of code,
cacheSave(). in order to actually send anything to the client then
it is the responsibility of the user of the caching tool to call
ob_end_flush() thus, invoking the method cacheSave()
it is also important that the script calling ob_end_flush() have access to
the definition of cacheSave() so it may have to be copied
into that script, or broken out into a separate script in order to be
included in the script calling ob_end_flush().
there is also another thing i ran into trouble with. that is the call to
the header method in the first bit of code in the cache tool.
header('Expires: '.gmdate('D, d M Y H:i:s',$cache_expires).' GMT');
the problem is that other scripts in the application may already be calling
the header() function, and therefore an error will be raised
since headers have already been sent by the cache code. would it negatively
impact the design of the cache to place the header()
invocation after the call to ob_start() ? that way it would not impact
other scripts that call header() since none of them will actually
be sent until the call to ob_end_flush().
unfortunately, i have been unable to get the tool to cache a single page
yet. mainly because this is my first real experience with
output buffering. i am eager to get it working, and if i can get it to
work; will likely see it installed on a production system. looking
forward to hearing from you.
thanks,
-nathan
On 6/26/07, Alexander Romanovich <andala@xxxxxxxxx> wrote:
Thank you for your reply Nathan.
You are right that this method of caching is different than the two types
you have outlined below. I would not say that it is a new method though, in
fact, "pushing static files" to the server is very common. If it weren't for
the fact that this method, as I have designed it, allows a very tiny PHP
overhead to handle dynamic updating of the cache I could have even gone the
extra mile to push html files that would be loaded directly by the end user
without PHP being initialized at all. (My reasons for not taking this last
step should become apparent to those who read the wishlist I produced at
http://technologies.babywhale.net/cache/ )
Understand that this method does not *exclude* using the other two methods
you have outlined. In fact, I personally make use of memcached and APC where
I feel it is appropriate in my application design. This does not mean that I
can not also write a cache layer that makes the application itself and its
variables irrelevant and not required for most site hits (hence a major
optimization).
To answer your other questions:
1) Caching on disk could easily be handled instead by caching in memory,
but this approach is meant to be ultra-portable and work everywhere. There
are situations where a viable memory storage mechanism is simply not
available, and other cases where it is not desirable to consume memory for
this purpose and plenty of hard drive storage space is a good alternative. I
think you will find this caching method is intensely speed-tuned and a
fast implementation of a portable file system based method. I would also
point out that in my line of work, where I chiefly have to adopt
environments that are configured under rather political circumstances, it is
consistently this type of caching that the system administrators argue
for. As someone has already pointed out, there may not even be a significant
difference between disk and memory based storage mechanisms on your server.
2) Again, one of the main theories behind this method is portability. In
order to not rely on cron, server queries, or other external checks for a
stale cache, I have gone with a "refresh interval" which has been proposed
on this list in the past. It proposes that dynamic content should be
refreshed once every X seconds/minutes/hours. This script avoids PHP date
manipulations and instead performs some basic math to handle the refresh
rate, but also to *sync* content to some degree, so portions of dynamic
content are less likely to haphazardly refresh independently and therefore
not match. I think this is a slight improvement over code that has been
posted here before. In a practical sense, this means that your application
fires and produces content only once every X minutes, and not each and every
time the page is hit. Furthermore, because in this case it is known ahead of
time when that page will expire, a cache header can be sent with an exact
expiration time so repeated hits by the same end user will not even trigger
a transmission of cached content from the server.
3) In regards to daily purging: for one, if you are going for a scheduled
refresh of content, then you probably already have a refresh rate that is
less than 24 hours, so accepting an additional daily trigger of recaching
should not be unacceptable. But more specifically, the reason behind this is
that a file system based caching method does not natively support a TTL on
cached files, and there has to be some way to handle a cache of a script
that has since been deleted. Note that if 24 hours is not acceptable for
some reason, this script can easily be modified to increase that without
negatively affecting anything else.
On Jun 24, 2007, at 11:55 PM, Nathan Nobbe wrote:
Alexander,
sorry to see nobody has replied to your post, im sure you worked very hard
on the cache system and are eager for feedback..
so to me it looks like youve introduced a somewhat new style of cachinghere (though im sure there are other such approaches); for instance i know
of 2 main uses for caches at this time [as caching pertains to php].
1. caching php intermediate code
2. caching application variables
both of these caching techniques are designed to overcome limitations of
the language as it ships out of the box, more or less; afaik.
it appears you are interested in caching the output of php scripts, which
is, i suppose, a third technique that could be added to the list.
so i have a criticism about your system and a couple questions as well.
*criticism*
- why cache script output on disk? if a fast cache is your goal,
why not store the result of script output in memory rather than on disk;
that would be much faster
*questions*
- how does your cache system know when cached output is stale and
allow fresh contents to be delivered from the original script rather than
being served from the cache?
- why purge cache contents after 24 hours? im on the memcached
mailing list, and recently they were discussing artificially resetting the
cache; several people said they let memcahe run for months on end.
-nathan
- Prev by Date: Re: [PHP] SQL Distinct-like behaviour
- Next by Date: Re: [PHP] check array values for all NULL
- Previous by thread: Getting different parent and child element classes from a single SimpleXML parse
- Next by thread: CURL receiving content data
- Index(es):
Relevant Pages
|
