I have an ASP .NET site with a custom server-side caching system which is a nightmare. I want to use eTags to replace this.
Many of the links in the site return different versions of a page depending on session state for the user. An example - mypage.aspx?p=a will return different versions of mypage - equally valid, depending on session state. I'd like to cache all versions.
Without totally redesigning the navigation links, how can I do this? From what I've read, putting a different eTag on each as they are generated and served for the first time will just cause the last-generated version to be invalidated and dropped from the cache.
Thanks
PS could I use Response.Cache.VaryByHeaders["Content-Length"] = true and rely on each version being different in length?
PPS Stupid idea! What about adding a custom header with a version key to the response and use VaryByHeaders on that.
The problem you have with custom headers is unless the thing at the other end understands them, they won't be reciprocated. So sending custom headers to IE will just result in it ignoring them.
You can use Output Caching though. It's possible to create your own outputcacheprovider. That would let you mess with the cache based on your requirements.
See http://msdn.microsoft.com/en-us/library/hdxfb6cy(VS.90).aspx for details on Output Caching.
It would appear the outputcacheprovider is only .Net 4
Related
I'm trying to cache user controls and on some pages i want to cache single objects. There are multiple ways of implementing caching, and my head is breaking over it.
The way I see the caching options now:
You have the PartialCaching option which is set to cache the control for 30 minutes, and after that it clears itself... You have the varyByParam to identity the page by its querystring paramaters... or other vary options
But i just cant find an appropriate way to add caching to a control, and be able to clear the caching programmatically when i update one of the objects used in the control from the backend.
You can do HttpContext.Current.Cache.Insert(), which accepts a key on which you can destroy the caching item later by using remove... This can save objects in cache but can you use options like varyByParam?
My questions are burnt down to two:
Is there a way to clear the caching on specific user controls from the code? If yes, can this be done according to the varyby options?
How would the object caching respond to logged in users or anonymous users using Insert()?
EDIT:
I'm caching multiple things.... And I'm really flabbergasted in which choice to make referring to caching. Can the Cache.Insert be varied by Parameters?
The main problem is peopling editing things from the backend, which needs to trigger an event that reinstantiates or clears all caching items referring that object.
You can remove items from the output cache using the following.
HttpResponse.RemoveOutputCacheItem("/caching/CacheForever.aspx");
Now, this is only going to get you part of what you are looking for. This will remove ALL cache entries for that specific page. The MSDN documentation confirms the behavior.
As to your other question Cache.Insert() is a single cache store across the application, user identity is not considered.
Now I would also take a bigger look at what you are doing, it might make sense to only cache the actual data and then you can add/remove the specific items. However, if your .control really does take a lot of CPU etc to handle the display then the output cache idea works.
Using the System.Web.Caching.Cache class you can cache items and create dependencies for the items in the cache. If you're using a SQL server, then you can use the SqlCacheDependency class to clear items from your cache based on your database.
Otherwise you can create your own derivatives of the CacheDependency class which you can use to accomplish the same thing. I found this post that describes doing that.
Let's assume you have a big complex index page, that shows news articles and stuff. It's not going to change very often. Can you cache it somehow on the serverside, so requests don't force to server to dynamically generate the entire page every time someone visits it? Or does ASP.NET do this automatically?
If so, how does it know if something has changed?
Yes you can, here is the declarative version of page caching, which will cache the page for 60 seconds:
You ask about changes, notice the VaryByParam part - you can, for example, ensure that there is one cached page for each parameter. You can even implement your own custom variation with VaryByCuston, which can be really powerful:
VaryByCustom
Any text that represents custom output caching requirements. If this attribute is given a value of browser, the cache is varied by browser name and major version information. If a custom string is entered, you must override the HttpApplication.GetVaryByCustomString
method in your application's Global.asax file.
Yes, caching exists, MSDN discusses it better than I can here. http://msdn.microsoft.com/en-us/library/06bh14hk.aspx
As I mention in an earlier question, I am having trouble with the performance of a web site... Some SQL queries are killing the server. But, as the title of this post mention, I looked at the OutputCache page directive to improve performance of the site.
Although, I came across some questions regarding this directive:
1- If I have a web-user control that declares an OuputCache directive in a page that has one too, which one will "win" ?
2- What's the best pratice regarding the duration ? I'd love to have a sliding window too.
Thanks for your help and please visit http://www.developerit.com
On a request where neither are cached, both the page and the control will be created, and then added to the output cache. If the page is cached, the control will not be created, regardless of whether it's in the cache or not--its markup is contained in the cached copy of the page. If the page is not cached and the control is, the cached markup of the control will be used in the page.
Here's a good article on Output caching: https://web.archive.org/web/20211020111708/https://www.4guysfromrolla.com/articles/121306-1.aspx.
Generally, you seem to be looking at Page and Fragment caching. What you want to do is cache the Page, if you can, as that will give you the best performance benefit. But, if you have regions on the page that must change dynamically per user, eg: you are saying 'Hi {username}' at the top of the page, then you need to look at Fragment caching.
Fragment caching is not as effective as page caching, since the output has to be stitched together from cached info and dynamic info, but it's usually still MUCH better than NO caching!
It's a bit of an art, to tweak the caching depending on what the page does and the load on the database, but it can make a page load many Orders of Magnitude faster than non-cached.
FYI - if the db queries are killing the site you may want to also look at taming them and/or caching their output individually, so that you don't have to keep hitting the database for the same information.
Also understand the 'varyByParam' for caching is pretty useful too - say you have a page in 3 languages, you can cache a page for each language by using the varyByParam, as long as your Url some sort of language component that the varyByParam can pick up.
HTH,
Lance
I think
beestings change the html every time.
this means html is not able to be cached.
am I right?
I assume that by beesting, you mean some sort of random number in the URL.
Yes this will (usually) stop caching of pages. Some browser may still cache some or all of the page.
As to whether not to avoid it. Would caching a page stop it working as it should? If your page has fairly random content or content the changes often, users would not see this if the page is cached.
If you can avoid the need to stop caching, pages will be able to load faster. Which makes for a happy user.
Old, old question, but anyway... no. You actually can "cache some or all of the response generated by an ASP.NET page, referred to in ASP.NET as output caching". You can read more at this Microsoft page.
For those still wandering, bee stings are special tags used in Microsoft's asp.NET to hold server-side code, much like PHP would do. It is, or was, very common to keep simple code inline, although having significant amount of code in bee stings is considered a bad practice by Microsoft themselves.
But as a rule, yeah, it can be cached.
Quick question.
There is a legacy website (that is not under my control and cannot be modified), that gives users a form to fill in data and then the user 'submits' the form for processing. There is virtually no error checking on this form, and very little help for the user (i.e. it was very poorly designed about 12 years ago and hasn't been updated since).
None-the-less, the back-end of this application performs a critical function.
My question is, is it possible (without having any ability to modify the legacy website), to write my own new front-end in asp.net (with proper pre-submit validation) living on a different server & domain, and then simulate the 'submit' to another webserver as long as I reproduce the form/data that is being sent?
The key question here I guess, is it possible to submit a form produce on one website, to another, and can this be done with ANY changes to the legacy site?
Comments appreciated.
The key question here I guess, is it possible to submit a form produce on one website, to another, and can this be done with ANY changes to the legacy site?
Yes, I've done this before - provided that the target site doesn't do any referer checking. A POST request is a POST request, no matter where it originates from.
You just need to make sure that all the fields are exactly the same in your request as they would be coming from the original page, i.e. - same field names, same encoding etc.
The short answer is "yes", the long answer is "it depends". The basics of HTML and HTTP allow for it, but without knowing a little more about the implementation of the legacy site you can't know for sure that it will work.
In theory you just need to make sure that the name of the fields are the same and set the target of the form to the legacy site's page URL.
In practice the legacy site could be doing various things that make it difficult or impossible to achieve (it could require cookies set correctly or hold internal state for example).
The best thing would be just to try it. It shouldn't take long just to mock up the basic fields and post the form to see if it works. Once you know it works then you can worry about adding your extra validation etc
Beware that if the existing site is authenticating users you'll need to find a way to also collect and pass that info along. Otherwise, though, Phill's point is spot-on.