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
Related
I am building my own GridView in an ASP.NET project
I am drawing out my plans and I was wondering what the best solution is to a simple problem, paging and sorting.
The fast and easy way is using submit buttons (or similar) and POSTING the form back. That's also how the ASP.NET gridview works.
pro:
less overhead
con:
backbuttons
The second method is using links and the URL with GET requests.
pro:
backbuttons work just fine
direct link to certain position
con:
less reusable because of the dependence on url
The third method is AJAX
pro:
little overhead
con:
harder to implement
What design/solution would you pick and why?
Am i overlooking some pros and cons?
I add some extra comments to think about.
-The second method is using links and the URL with GET requests.
This is the one that you need to use, if your need web spiders (google) knows all the pages of your site, and be SEO friendly. This method have the problem that you can not have viewstate and each time you must render the page that you see on the url parameters with out knowing anything else.
With this case you probably have more problems if you wish to make edit on one line
-The fast and easy way is using submit buttons (or similar) and POSTING the form back
This is the method if you won to have many functionality on code behind because with the post back you have all the previous action that you have done, and the viewstate is working and can be used for that. Is not SEO friendly and if you like to make it you need extra code to write on the url just the page that you are now and need to land.
-The third method is AJAX
This is the method that must co-exist with the previous and not alone for the case that the browser fails to run javascript for any reason. If you do not care about that, the rest is that this method is also not SEO friendly and you need to make it, is cool, modern, and is a must for modern site, but if you going to make difficult things then you may end up with many issues that must be solved.
To summarize:
More than show data ? Post Request : Get Request ; // ToDo: make it ajax
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
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.
I am new to asp.net and have got some concerns about the bloated viewstate on a small site I'll be maintaining.
Since I actually don't want to learn asp.net (mvc looks interesting though), my question is if I should care about this potential issue or just wait 4 years until its time to rewrite the site....
Hopefully some of you have some experience or already have done a proper research to help me decide if it's worth the time to do something about it.
I am not interested in workarounds since if this is a serious issue I have found info about different ways to reduce the viewstate. (Although it requires me to understand the framework and code.)
Thanks.
some search engines only process the first few KBs of the page if the page size is large. As viewstate is a hidden input at the top of the form/page this can impact SEO as the actual content of the page may not get fully processed by the search engine if there is too much viewstate. Look into moving the viewstate to the bottom of the page.
http://www.hanselman.com/blog/MovingViewStateToTheBottomOfThePage.aspx
It can cause excessive page weight but this will not hurt your standing with the search engines. ViewState is stored in a hidden input which are mainly ignored by search engines.
I know this thread is old but in ASP.Net every control including the page itself has a property called EnableViewState. All one has to do is turn it to false if they do not need a control to maintain state or for that matter the page itself
I'm looking for some help on my discussion. We're discussing two solutions to a customization problem. One uses (nested) master-pages. One master page per customized page. Plus there is a standard master page for all pages. The second uses a standard page, which redirects to the custom page if it exists.
My question is, which is more desirable? Having to Load 2 master pages every time OR only having to load 1 master page and sometimes redirecting (Response.Redirect or Server.Transfer) to the customized page.
I can't really find any information on master page performance. Should I just think of them as another (somewhat inverted) user-control or should they be used lightly?
Edit:
You can assume Response.Redirect for the transfer.
You can assume the Redirect occurs in the PreInit stage of the lifecycle.
Master pages are in a sense inverted user controls (they "surround" content as opposed to user control content that is pushed into the page). There isn't a rule of thumb that says use master pages lightly--a master page's performance cost is directly proportionate to how much code (HTML and otherwise) it causes to be pushed into the HTTP data stream.
For my money, I'd land on the side what makes for the most readable and maintainable code.
so, it's a webform application no matter what, right? Did you ponder Model View Controller perspective?
Regarding the nasted MasterPages, I did that on a client CRM application and I can assure you, you do not fell any problems loading unless the usual ones about the internet and server speed, for that, and if you think it's the best way to accomplish or objectives, go for it.
Each Master Page will fire their events and normally we think about ohh well, 2 master pages plus a content or several content pages could be a problem pointing the loading time, but this takes miliseconds performing all this, so... be safe.
the only thing that you need to take care is, don't fell up with all the javascript addons that you can find, choose a nice library and use only that, JQuery (now on version 1.3.0 would be the best choice).
at least that is my opinion :)