Please advise about caching

Hello,
I tried out using the cache the other day and was impressed with the
concept. I built myself a custom control to generate the site links,
using an XML file for the info. I kept the XML file in the cache and
added a dependency so it will notice when the file changes. All fine so
far.
I was reading last night about using the OutputCache page directive to
store the page in the cache. It seems you can do this for a user control
as well, allowing you to cache part of a page.
So, my question is, which is more appropriate, using the cache manually
or using the OutputCache page directive? Obviously each will have its
uses, but consider the following ...
I have an e-commerce site written in Classic ASP. I am looking to
rewrite it in ASP.NET at some point. One weakness of the existing
version is that product pages are generated dynamically from a database.
I had been looking at a method whereby when the database is updated, the
HTML is created for the product and written to disk, avoiding the
necessity to hit the database each time the page is displayed.
I am now wondering if it would be better to generate the HTML and store
it in the cache. I could either write the part of the page that displays
that product details as a custom control and use OutputCache to cache
that control, or generate the HTML myself and add it manually to the
cache. Either way I would need some mechanism for checking when the
database is updated, but that's a separate issue.
So, any suggestions? Anything to sway me one way or the other?
One factor I would like to consider is the life of an object in the
cache. The OutputCache directive takes a Duration parameter, which means
that come what May, the HTML will be dropped from the cache when it
expires 9if not sooner). If I put it in the cache manually, AFAIK it
will stay there until it gets kicked out for lack of space. Presumably
an object that is called often is less likely to get kicked out, so the
HTML for the most popular products will stay in the cache the longest,
ensuring maximum efficiency. Is this right?
TIA for any comments on this long waffly post ;-)
Alan Silver
(anything added below this line is nothing to do with me)Alan:
Generally I like to use OutputCache whenever possible, and storing things in
the HttpCache after. OutputCache caches the entire rendered HTML,
HttpCache.Insert/Add only chunks of data (in other words you still need to
render the output).
In IIS 6.0, outputcache is automatically hosted in the kernel which makes it
even faster. In 2.0 outputcache will be even more flexible AND allow you to
store it to the file which will let it last forever (if you wanted to).
As far as performance, the closer to the final product you can cache
(outputcache) the better. And while I typically don't harp on performance,
that's the point of caching so...
Karl
--
MY ASP.Net tutorials
http://www.openmymind.net/
"Alan Silver" <alan-silver@.nospam.thanx> wrote in message
news:JLmJ3uERv3CCFwyT@.nospamthankyou.spam...
> Hello,
> I tried out using the cache the other day and was impressed with the
> concept. I built myself a custom control to generate the site links,
> using an XML file for the info. I kept the XML file in the cache and
> added a dependency so it will notice when the file changes. All fine so
> far.
> I was reading last night about using the OutputCache page directive to
> store the page in the cache. It seems you can do this for a user control
> as well, allowing you to cache part of a page.
> So, my question is, which is more appropriate, using the cache manually
> or using the OutputCache page directive? Obviously each will have its
> uses, but consider the following ...
> I have an e-commerce site written in Classic ASP. I am looking to
> rewrite it in ASP.NET at some point. One weakness of the existing
> version is that product pages are generated dynamically from a database.
> I had been looking at a method whereby when the database is updated, the
> HTML is created for the product and written to disk, avoiding the
> necessity to hit the database each time the page is displayed.
> I am now wondering if it would be better to generate the HTML and store
> it in the cache. I could either write the part of the page that displays
> that product details as a custom control and use OutputCache to cache
> that control, or generate the HTML myself and add it manually to the
> cache. Either way I would need some mechanism for checking when the
> database is updated, but that's a separate issue.
> So, any suggestions? Anything to sway me one way or the other?
> One factor I would like to consider is the life of an object in the
> cache. The OutputCache directive takes a Duration parameter, which means
> that come what May, the HTML will be dropped from the cache when it
> expires 9if not sooner). If I put it in the cache manually, AFAIK it
> will stay there until it gets kicked out for lack of space. Presumably
> an object that is called often is less likely to get kicked out, so the
> HTML for the most popular products will stay in the cache the longest,
> ensuring maximum efficiency. Is this right?
> TIA for any comments on this long waffly post ;-)
> --
> Alan Silver
> (anything added below this line is nothing to do with me)
>Alan:
>Generally I like to use OutputCache whenever possible, and storing things i
n
>the HttpCache after. OutputCache caches the entire rendered HTML,
>HttpCache.Insert/Add only chunks of data (in other words you still need to
>render the output).
OK, that's not such a huge problem, it's only a case of pulling it from
the cache and writing it out.
I was more thinking about the issue of how long objects live in the
cache. If I put them in myself, won't they stay there until the cache
gets full? Also, I'm assuming that when objects get dropped form the
cache, the least recently used ones will go first. If so, then the HTML
for the most frequently accessed pages will stay in the cache the
longest, giving the best performance increase.
If I understand the OutputCache right, objects will only stay in the
cache for the time specified. That way, even the frequently accessed
bits will be dropped. This sounds less efficient.
Or have I got it completely wrong ;-)
Thanks for the reply. Any further info would be greatly appreciated.
Alan Silver
(anything added below this line is nothing to do with me)
Alan:
I wouldn't say one will last in the cache longer than the other. HttpCache
can also have a time to stay in cache (either as an absolute or a "from last
access"). So in that sense you have more control. I wouldn't make any
assumptions about how/when items are dumped from the cache for two reasons.
First it's probably complicated. Second you shoulnd't assume it's in the
cache technically (ie, it isn't guaranteed to be there, so you need to write
the code to get it form the store if it isn't). Having said that, you can
specify the Priority with HttpCache, again giving you more control, but
adding to the complexity of what/when will be dropped. I would expect a
number of factors to play into the decision, such as priority, time last
used, size, frequency of use, available memory, ....
if you are worried about the duration of output cache, put it as 86400 (a
day)... There's no doubt though that HttpCache provides more flexibility
(priority, absolute vs relative time, dependencies (big one)).
Karl
MY ASP.Net tutorials
http://www.openmymind.net/
"Alan Silver" <alan-silver@.nospam.thanx> wrote in message
news:MFwoUbGJH5CCFwSE@.nospamthankyou.spam...
in
to
> OK, that's not such a huge problem, it's only a case of pulling it from
> the cache and writing it out.
> I was more thinking about the issue of how long objects live in the
> cache. If I put them in myself, won't they stay there until the cache
> gets full? Also, I'm assuming that when objects get dropped form the
> cache, the least recently used ones will go first. If so, then the HTML
> for the most frequently accessed pages will stay in the cache the
> longest, giving the best performance increase.
> If I understand the OutputCache right, objects will only stay in the
> cache for the time specified. That way, even the frequently accessed
> bits will be dropped. This sounds less efficient.
> Or have I got it completely wrong ;-)
> Thanks for the reply. Any further info would be greatly appreciated.
> --
> Alan Silver
> (anything added below this line is nothing to do with me)
>Alan:
>I wouldn't say one will last in the cache longer than the other. HttpCache
>can also have a time to stay in cache (either as an absolute or a "from las
t
>access"). So in that sense you have more control. I wouldn't make any
>assumptions about how/when items are dumped from the cache for two reasons.
>First it's probably complicated. Second you shoulnd't assume it's in the
>cache technically (ie, it isn't guaranteed to be there, so you need to writ
e
>the code to get it form the store if it isn't). Having said that, you can
>specify the Priority with HttpCache, again giving you more control, but
>adding to the complexity of what/when will be dropped. I would expect a
>number of factors to play into the decision, such as priority, time last
>used, size, frequency of use, available memory, ....
>if you are worried about the duration of output cache, put it as 86400 (a
>day)... There's no doubt though that HttpCache provides more flexibility
>(priority, absolute vs relative time, dependencies (big one)).
Thanks for the advice. Maybe I'll just write the code as a custom
control with the OutputCache directive and let .NET handle the hard work
for me!! I can always look at optimising the caching later. From what
you say it sounds like OutputCache is a better option (assuming that
this is what you mean by HttpCache), so I'll use that.
Thanks again
Alan Silver
(anything added below this line is nothing to do with me)