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 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).

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...
> >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).
> 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)).

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)

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)

Please advise me

Hi Everybody,

I am very much novice to .NET.At present i am working in C,Unix Product development.I got no experience in .net infact i am a fresher who is holding months of experience.I am interested in .net development also am anticipating some development works in .net in my firm.

i dont have any knowledge in this domain.and dont know how to start.

Having said by some of my collegues that asp.net and C# are having better oppurtunities today i want to choose the same path to start up my carrer in .Net .

Can any one please kindly advise me how to start up with .net and what meterial to follow?

Awaiting for your response

Thank you

with regards,

Srikanth

Hi,

and welcome to the ASP.NET forums.

You can freely download the VWD Express tool on this site, take the Tutorials and follow the Guided tour. That'll give you some insight. I read that you already developed with C so I would like to advice you to learn C# as your main development language in .NET.

If you're looking for a decent book you can search through the Book reviews forum and if you should have questions you can visit the forums and ask them.

Grz, Kris.

PS: have fun!

Welcome!

Download VWD Express edition from www.asp.net site. In this edition webserver is in built, no need of IIS for development purpose.

To know about asp.net refer following link:

http://samples.gotdotnet.com/quickstart/aspplus/doc/whatisaspx.aspx

If you don't about web programming, I suggest you to read basics ofHTML (tags) , JavaScript (useful for client side programming), .NETframework architecture.

Best of luck.

For any further difficulties in ASP.NET please visit this forum.

:-)

Regards

Kuldeep Deokule.

deokule2003 wrote:

If you don't about web programming, I suggest you to read basics of HTML (tags) , JavaScript (useful for client side programming), .NET framework architecture.

A nice site to learn more about these ishttp://www.w3schools.com/ or you can also take a look at the official documents:http://www.w3.org/TR/.

Grz, Kris.

Please advise on how to create an invoice system

i'm trying to create an asp webform for my own development. I'm trying to create an online invoice where people can enter details like "Customer Name, Address, Date, Total amount".

I'm able to create a webform which captures those details and insert/delete/delete to/from a mssql db.

But because each invoice should have some items, so i created another table (InvoiceDetails) which reference to the Invoice table. So i can create as many items as i want in each invoice.

How should i create webforms for the invoicedetails? Because i need to add dynamically and not fix 10 records to add/edit in the form. THus most probably i'll need to put all sql statements into 1 transaction in case 1 InvoiceDetail record fail, so i can rollback the Invoice and InvoiceDetail record.

are there any samples which has a similar scenario as me?Its an interesting scenario Michael, especially the cardinality of relationship & dynamic nature of this application. If formatting doesn't matter much at data-entry level, you can use editable datagrid to insert/edit/delete data. This will totally accomodate the dynamic nature of InvoiceDetails using this strong data-aware component in ASP.NET. However, for printing & display in invoice report format, you may need to postion the dynamic controls on the fly which may get difficult if positions need customized.

MSDN's article "Adding Controls to a Web Forms Page Programmatically" may help.
http://msdn.microsoft.com/library/en-us/vbcon/html/vbtskaddingcontrolstowebformspageprogrammatically.asp?frame=true

I hope it helps.

-Adnan Masood
This is a job for a new application model. HTML sucks for this stuff. Imagine writing an ERP application for the Web.. Wait Oracle did it.. sort of.

You will probably want to employ some thrd party web controls from the folks at Infragistics. Adding detail lines to invoices without them will be a little kludgy.

I did it once and ended up doing it with a series of frames. A button on the header page took you to a detail page. After adding the data on the detail page you went back to the header. It was a lot of tedious work.
Hmm, I would have a form that adds a single item to the order. Then two buttons, one says "Add another item" and one says "Finish Order". Add another item just reloads the form and Finish Order goes to whatever the next step is.

For editing just use a datalist that binds to the order number.

I do a similar type system for magazine advertising rates for each year. A particular magazine can have 10 years worth of prices and each year can have 20 different rates (for various sizes). The datalist shows all 10 years (queried by the magazine ID) and when they select the edit button it changes all the prices into textboxes for that year only. So your datalist would show all items for a single order, and then allow editing of each individual item inside that order.
hmm... datalist.. but what if its a new invoice? Thus it will not be given a Invoice ID until its inserted into the database. So its kinda hard to bind the individual items to that invoice

thats why i'm asking for advise on whats the best practise for people who has done similar development..
While you are entering the invoice keep the database in some temp tables. Identify the record with a GUID.. after you are done editing copy that data from the temp tables into the production tables. This works well and requires no whacky state management. It depends on the level of sophistication you want. In my current business we don;t start out by entering an order/invoice. We enter contracts the contracts get attached to jobs and several people may be involved with entering the data about the contracts and jobs. As the work on the contract proceeds incremental invoices are issued.