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 Help

Let me start by saying that this is a custom shopping cart application, built using Visual Web Developer with an SQL 2005 Express database. This is my first real project so most of these things are new to me. For the most part, everything works, you can log in, navigate around and whatever, but the process of adding products to your cart and viewing your cart seems just that bit too hard.

The database has Products, Categories, Manufacturers, Customers and Orders tables (you'll find out the important fields later) and a membership provider has been implemented to store user details in the Customers table, those being Name, Password and E-Mail along with an automatically incremented ID.

An "Administration" section has been set up to allow people to create and modify the products, categories and manufacturers. This generates a menu on the left hand side which has links to "~/Details.aspx?CategoryID={0}" which brings up a page with a GridView control showing information about every item that belongs to the category specified in the QueryString. In this GridView, the important columns are ProductID (which has a Label), Quantity (which has a TextBox) and Add (which has a Button).

In order to add products to a customer's cart, we must do the following, which is where it gets too complicated for me...
- get the user's CustomerName and corresponding CustomerID and enter that in the Orders table
- get the ProductID of the appropriate row (the one where the button was clicked)
- get the value from the Quantity of the appropriate row

For example, finding the CustomerName is easy...

Dim CustomerNameAs String = Context.User.Identity.Name

...but then finding the CustomerID of that user and using it as a parameter in SQL is too hard.

My only idea as far as the ProductID and Quantity goes was to make the "Add" button select the row, then find the information from the selected row.

Answering the above problems would also solve this one, but then when the user goes to view their cart, we have to filter the data to only show the orders with their CustomerID. Again, that means finding the CustomerName, then corresponding CustomerID, then saying "WHERE (Orders.CustomerID = *insert parameter here*).

If someone could help me figure out these issues it would be much appreciated.

Thanks.

Managed to fix the issue regarding the CustomerID and CustomerName, but it's not the nicest of solutions.

Dim UserAs String = Context.User.Identity.NameCustomerName.Text = User

Just takes a hidden TextBox, assigns it the value of the user's name and that's used as a ControlParameter. But, as above, there should be a cleaner way of doing this and besides, it only helps with the "View Cart" page, not adding items to your cart. This is because of the following clause in the SQL...

WHERE (Customers.CustomerName = @.CustomerName AND Orders.CustomerID = Customers.CustomerID)

...but the corresponding CustomerID is still needed for adding products.

Can somebody please help me out here?

It seems a "INSERT INTO...SELECT" statement is required, we're reading up on it at the moment and trying to get it working, but some assistance would still be welcome.

For example, what is the syntax for using "INSERT INTO...SELECT" to get values from another table, while also using parameters from the page in the same statement, something like this?

INSERT INTO Orders (CustomerID, ProductID, Quantity) VALUES ("SELECT CustomerID FROM Customers WHERE CustomerName = @.CustomerName", @.ProductID, @.Quantity)

Obviously, that's the wrong syntax, but it should help to understand what we're trying to do.

Made some progress here, managing to figure out the correct SQL statement (which is below if you're interested).

The problem is, we must use controls from the corresponding row of the GridView, according to which "Add" button was clicked. To do this, we thought it would be easy to just select the row and use GridView.Rows(GridView.SelectedIndex).FindControl and to an extent that works. However, with CommandName="Select" and OnClick="Add", the latter is fired first, which means that the row is not selected.

How can we get the row to be selected before the OnClick event is triggered?

Thanks.

"INSERT INTO [Orders] ([CustomerID], [ProductID], [Quantity]) SELECT [CustomerID], @.ProductID, @.Quantity FROM [Customers] WHERE ([CustomerName] = @.User)"