"Joel W. Reed" wrote:
>
> On Sep 12, [EMAIL PROTECTED] contorted a few electrons to say...
> Joshua> Hey,
> Joshua>
> Joshua> I'm working on an includes output caching mechanism, based
> Joshua> on the same dbm cache layer just released for the XSLTCache.
> Joshua> The functionality would allow for the output from an include
> Joshua> to be cached based on some optional key for a specified amount
> Joshua> of time. So if an include might take 100ms to execute, and
> Joshua> the cache only takes 5ms to fetch from, there could be
> Joshua> a 20x savings for that part of the script.
> Joshua>
>
> very cool. i thought it might be helpful to see what M$
> does around server-side caching.
>
> 1). Options in ASP.NET (good data points here -imho)
>
> http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconaspcachingfeatures.asp
>
Thanks for the link. I think what I will end up implementing
will support & extend the $Response->Cache() syntax for caching
the entire page. Though certainly supporting the declarative
approach would be a good thing too!
> (it seems they prefer a declarative approach to
> controlling the caching of pages)
>
> 2). The info on IIS4.0/ASP seems more sketchy. From
> http://support.microsoft.com/support/kb/articles/Q189/4/09.ASP
>
This is interesting. The Expires header should refer to the
browser cache, but it seems that they might be using it
to do a web server level cache too. I have thought about
using Expires in this way to enable web server caching,
but I feel that confusing browser level cache with
web level cache might be confusing. I'll consider this
when implementing the $Response->Cache() feature, how
expires might play into this.
Actually a server level cache might make MORE sense than browser
level for Expires, because web browser clocks may be set to
whatever, and expires dates are absolute & not relative.
> 3). while on the subject of performance in ASP apps here's
> something interesting:
>
> (emphasis mine)
>
> If the user gets impatient, he or she may abandon your ASP page before
> you even start executing their request. If he clicks Refresh or moves
> to a different page on your server, you will have a new request
Unfortunately, it seems that $Response->{IsClientConnected} can
only be updated after a $Response->Flush() because Apache doesn't
update its $r->connection->aborted record until a $r->print()
is done. If anyone knows anything different let me know, as then
I could refresh the IsClientConnected value before Script_OnStart runs
which could be useful for globally ending scripts.
Alternatives to this common problem include serializing session
access with SessionSerialize or $Session->Lock() and do a flush
& test. What this will do is make sure requests from the same
browser queue up, and you can check each request one at a time
like so:
sub Script_OnStart {
$Session->Lock();
$Response->Flush();
$Response->{IsClientConnected} || $Response->End;
}
Unfortunately, once you flush, your headers have been sent out,
so you can no longer do things like $Response->Cookies()
or $Response->Expires
I'll check on the mod_perl list to see if anyone knows
how to detect a client aborted without an $r->print() being
called first.
--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]
