Just a quick question so I full understand this better, the way I understand it currently is if you set a page to be cached the HTML generated is essentially saved and then reserved.
This means no code behind on that page is run until the cache expries and regenerates. Also, if say for example I have a dynamically generated date stamp, this will always be the date the cache was generated.
Is this correct?
Read the artice about caching. If you want to fully understand Http Caching, you should also read Caching In Http. And the answer is yes, once the page is saved in cache, no code behind is run before it's regenerated. Also, dynamically generated content will stay in cached page as static
Yes, but you can flag some portions of code or some controls to be rewrited.
You can catch only some controls or all controls except one...
Catch the data from database or some collections...
Is a lot flexible.
Related
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.
Is there any way that I can list the pages which are currently stored in the OutputCache?
Just a list of paths would do, but if there's a way to get more information about each item (expiry etc), then all the better.
As far as I remember Cache is a singleton and there is only one instance of it per app domain. OutputCache uses it too and it's nothing more than just a Response.Cache. So I think cached pages should be available through the Cache (Sorry, I can't check this at the moment). And the following articles should help you in this case:
http://www.codeproject.com/KB/session/exploresessionandcache.aspx
http://aspalliance.com/CacheManager/Default.aspx
Here is a little tool I wrote that will let you to view the contents of your Cache. You can also view the dependencies on a file and remove the cache.
https://github.com/azamsharp/WIYC
Here is another tool that displays the Usercontrol(Webforms) cache and am extending that to display the outputcache details as well
https://github.com/chandarmk/InternalCacheHandler
The ASP.NET ScriptManager control automatically inserts all kinds of inline javascript like PageRequest initialize. Is it possible to remove or move this to an external js file?
Also, the scriptmanager always adds __DoPostback even when not used on the page, how can this be avoided or also moved to an external file?
First of all the "__DoPostBack" is inserted by controls that can cause a postback such as the DropDownList with the AutoPostBack property set to true. Since the ScriptManager basically intercepts the traditional postbacks, I believe that's the reason for it to insert the function.
-- The following is just me thinking... :)
Now, about moving everything to an external file. It's not easy, but it "could" be possible.
The problem is that ASP.NET is generating the scripts at runtime, so you cannot do anything about it statically. What you need to consider is why you would want to do this in the first place.
The fact is that much of the generated script is dynamic, which makes it rather hard to cache.
But, if you really need to, you should have a look at both HttpHandlers and HttpModules.
Basically you need to somehow extract every script tag (without the src-attribute set). This could be done in a HttpModule on the BeginRequest event of the HttpContext. Now you need to extract all the necessary pieces of information and replace it with a reference to a specific HttpHandler that can service as the replacement.
But to make any difference at all, it is necessary for you to do some sort of caching of the existing script. You could probably use the ASP.NET Cache for that.
The tricky part would be to compare an existing cache entry with the new and determine whether or not to get the cached version (pointing the HttpHandler to an existing entry) or to generate a new entry. If you have a lot of scripts, it's most likely to be a rather expensive operation.
Furthermore you need to determine whether the client can cache on it's own (e-tags etc. could come in handy). What's important is for the client to avoid downloading the same unnecessary scripts each time (I believe that's your ultimate goal?).
So to recap:
Build a HttpModule to take care of the page rewriting and putting the extracted script into some sort of cache (eg. ASP.NET Cache).
Build a HttpHandler to point to for the extracted script (it should stream the contents from the cache). The handler should be put in place of the extracted inline scripts.
Create some sort of algorithm for determining cache invalidity. I don't know from the top of my head what kind of script that could change between requests.
Btw. script externalization is tricky at most, so you need to be careful not to introduce bugs that are impossible to fix ;)
Not an extact solution, but I have tried doing this myself before without any luck... mostly because of too litle time. When you are payed to do a task, this kind of optimization can't be justified... :(