Philip Mak wrote:
>
Thanks for the feedback. Its much appreciated.
> On Wed, 12 Sep 2001, Joshua Chamas wrote:
>
> > $Response->Include({
> > File => 'file.inc',
> > Cache => 3600, # to cache one hour
> > Key => [\%data || \@data || \$data || $data || undef]
> > },
> > @args
> > );
>
> Why is there a time limit on how long something can be cached? Wouldn't
> someone usually want the page to be cached indefinitely (space
> permitting)? I guess if someone doesn't specify a time limit, it should be
> infinite.
>
OK, a Cache => 1 key to start caching, with an Expires => 3600
to specify for only one hour. Without Expires set, the caching
would be indefinite, or until the web server restarts. See below
for full API example.
> I'm guessing there should be a directive that allows someone to set the
> maximum number of bytes that the cache is allowed to take (e.g. PerlSetVar
> MaxCacheSize), and some LRU/LFU policy could be employed when the cache
> fills up.
>
The directive CacheSize, in bytes, already supports this. The same
cache size will be used for the XSLT cache, Includes/Script(TODO) cache, and
users cache(TODO). The default is 10000000, so using all three caches
could take nearly 30M. I don't want each to be specified separately,
there are already too many configs as it is.
> Let's see...we have three kinds of server restarts:
>
> 1. apachectl graceful
> 2. apachectl restart
> 3. apachectl stop; apachectl start
>
The kind of cache expiration I would implement would probably
occur under all 2 + 3 scenarios, because the cache expiration uses
the process pid $$ of the parent httpd as part of the key. I believe
graceful keeps the parent httpd the same.
> I'm guessing you were asking about case #2. IIRC, when someone does
> "apachectl restart", all the modules are recompiled, so I think you'd HAVE
> to clear the cache too, otherwise weird things can happen.
>
It all depends on the parent pid under this condition. Me, I always
stop/start now. I got tired to dealing with all the oddities that
come up under graceful/restart.
> As for case #1, it might be useful to be able to clear the cache without
> shutting down the server completely, although I'm not saying that *I* need
> that functionality.
>
Hmmm, let's hope no one wants this. :)
> Another thought: What if I want the entire contents of a script to be
> cached? e.g. I want "page.asp" to be cached based on its query string.
> Would I have to put this:
>
> <% $Response.Include({
> File => 'real_page.inc',
> Key => $Request->QueryString
> }); %>
>
For now, yes, but I would like an API that deals with this too, just
not yet. I imagine it would look like
$Response->Cache({ Key => $data, Expires => 3600 });
That said, perhaps the include cache API would look better as
$Response->Include({
Cache => 1,
Expires => 3600, # or none for forever
Key => $data,
}, @args);
That would certainly look more consistent. There will be a user
cache one day too, and I think it will look like:
$Server->Cache($key, [$value, $expires]);
or
$Server->Cache( { Key => $key, [ Value => $value, Expires => 7200 ] });
> Another thought: How would we do conditional cache refreshing? e.g. let's
> say I have a script "view.asp?id=5". The results of this script should be
> cached, BUT if the entry in the database for 5 has changed, it should not
> be pulled from the cache. How about something like this, then:
>
> <%
> my $id = $Request->QueryString('id');
> my $time = $dbh->selectrow_array("SELECT modified FROM
> data WHERE id=".$dbh->quote($id);
> $Response->Include({
> file => 'view.inc',
> key => $id,
> timestamp => $time
> });
>
Maybe a Clear argument like:
$Response->Include({
Cache => 1,
Expires => 3600, # or none for forever
Key => $data,
Clear => 1
}, @args);
This would force the data to be re-cached. Clear
might also take a sub ref that if executed and returned
true would also force the include to be recached.
$Response->Include({
Cache => 1,
Expires => 3600, # or none for forever
Key => $data,
Clear => sub { &check_db($Session) }
}, @args);
> to invalidate that cache entry. "modified" would be a TIMESTAMP column in
> MySQL, which automatically gets touched if that row is updated. There
> could also be an "invalidate" parameter, which if true, will tell
> $Response->Include not to pull the page from the cache under any
> circumstances. It's probably useless if we have "timestamp" available,
I think that the invalidate parameter is the Clear I suggest,
and that Clear could be used to effectively deal with the timestamp
issue, but the logic must exist outside the caching mechanism.
> 1. Add a MaxCacheSize config parameter to allocate disk space for the cache
> 2. Clear cache on "restart"; maybe make config parameter to allow clearing
> cache on "graceful"
> 3. Is it a bit cumbersome to need to create an entire file just as a cache
> directive? Can we do better?
> 4. Perhaps add a "timestamp" and/or "invalidate" parameter to
> $Response->Include to allow more powerful cache control
>
> Ack, did I create more questions than I answered? :)
>
I think I hit all these. Let me know whether you like the
Expires & Clear keys as additional arguments to the
$Response->Include(\%attr) API. You'll have to wait for
the equivalent $Response->Cache() & $Server->Cache() though!
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
