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
(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
"ISAPI applications (Active Server Pages Web pages) can be cached on
Internet Information Server. When you create a new IIS 4 application,
caching of ISAPI Applications is on by default. "
and
At the top of the .asp page that you do not want cached, add the
following line:
<% Response.Expires=0 %>
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
sitting at the end of the ASP request queue and a disconnected request
sitting in the middle of the queue. Often this happens when your
server is under high load (so it has a long request queue, with
correspondingly high response times) and this only makes the situation
worse. There's no point executing an ASP page (especially a slow,
heavyweight ASP page) if the user is no longer connected. You can
check for this condition by using the Response.IsClientConnected
property. If it returns False, you should call Response.End and
abandon the rest of the page. IN FACT, IIS 5.0 CODIFIES THIS
PRACTICE WHENEVER ASP IS ABOUT TO EXECUTE A NEW REQUEST, IT CHECKS TO
SEE HOW LONG THE REQUEST HAS BEEN IN THE QUEUE. IF IT HAS BEEN THERE
FOR MORE THAN 3 SECONDS, ASP WILL CHECK TO SEE IF THE CLIENT IS STILL
CONNECTED AND IMMEDIATELY TERMINATE THE REQUEST IF IT'S NOT. You can
use the AspQueueConnectionTestTime setting in the metabase to adjust
this timeout of 3 seconds.
If you have a page that takes a very long time to execute, you may
also want to check Response.IsClientConnected at intervals. When
response buffering is enabled, it is a good idea to do Response.Flush
at intervals to give the user the impression that something is
happening.
from:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnasp/html/asptips.asp
--
------------------------------------------------------------------------
Joel W. Reed 412-257-3881
--------------All the simple programs have been written.----------------
PGP signature
