IIS has featured to set "Output Caching" on asp.net sites. I would like to know what is the benefit of this type of caching compared to caching done by our browser.
I am wondering because if our browser has the power to cache content(such as js/css/image), why would .net implement feature such as output caching?
Imagine a page that takes a lot of server-side resources to create -- maybe database calls, heavy computation, etc.
If one user requests that page, and it gets cached by the browser, then the next time that user requests the same page, it will already be on their machine -- so it won't have to be generated by the server or transferred over the network again.
Next, imagine that a second user requests the same page. The fact that a copy of the page was cached by the first user's browser doesn't help. Without output caching, the server will need to perform those time-consuming operations all over again to generate the page.
If the page used output caching, then the results from the first time is was created would be stored in memory on the server, so the cached results could be sent in response to subsequent requests -- which saves time and server-side resources.
Think of it for multiple users, let´s say 100.
Without Output Caching IIS would have to process and generate the page for each user request so the page is processed 100 times.
With Output Caching IIS would have to process the page once (for the first user requesting it), then cache it and return the same version for the other 99 users.
Related
Can someone give me a good reason why ViewState isn't stored on the server by default?
Why not send a small session token in place of ViewState, which can then be mapped to whatever ViewState info is needed on the server, to prevent the whole ViewState being posted back and forwards multiple times.
Am I missing something?
Scalability - imagine how much server resources would be needed if a complex WebForms page was viewed by 1M users. Server would need to hold ViewState for at least the duration of the session timeout. Automatic server side cleanup of viewstate would also be problematic - user may be viewing several pages at once so ViewState for all pages would need to be retained.
Edit
There are several techniques discussed in these posts on how to move viewstate to the server. However, before you do that, it would be a good idea to remove unnecessary viewstate from controls / pages which don't need it (e.g. View only / no postback rendering).
I'm guessing now, but when viewstate was designed 10 years or so ago, 1GB RAM on a 32 bit server was about as good as it got, and MS presumably had to think of hosting providers wanting load 100's of apps per server. So bandwidth was probably viewed as cheaper than server Ram and disk storage.
There are a number of issues with storing the ViewState in memory.
If the application recycles, the VS for all anyone using the application is lost.
It increases the memory consumption of the application. This isn't an issue if there are only a few apps hosted on a server; but there are cases when there could be many websites hosted on one box.
Scalability; the more active the application, the more VS needs to be stored. And you can't assume 1-1 (1 user - 1 VS). A user can have multiple tabs open, can go back, leave tabs inactive, etc... which leads to:
How long do you store VS? Keeping the data encoded on the page ensures that it'll still be there if the user leaves the site open for a while.
What happens if you're hosted on a web farm. We can't guarantee that the user will hit the same machine on each request.
That being said, there are a few solutions:
Memcached-Viewstate - stores the VS in distributed memory using Memcache. This isn't ideal - if a server goes down the VS for anyone who had the VS stored to that server is lost, but will allow for application pools to reset without issue.
SQL-Viewstate - stores the VS in a SQL database. This adds a least 1 DB read and 1 DB write per request. Again, not ideal, but if the VS is getting unmanagable getting and setting the VS from the database is faster than sending and recieving it over HTTP.
Filesystem-Viewstate - stores the VS in the filesystem. It's less expensive than the SQL connection but would require a file server to work in a distributed environment.
It improves scalability because the server doesn't need to maintain all of that in memory. It is possible to store the viewstate in session but it's generally not recommended.
The root cause is using client side view state is that server doesn't know the current state of the page.
If a user is anxious, does multiple (partial) postback on the page, without waiting the response, browser will send out multiple partial postback requests, that each request create a new view state on server side, which will eventually flush out the initial view state in the browser. Finally the user does his last postback, at that time, the inital copy is gone, thus exception is thrown.
Also server side view state impacts server performance and user experience. If a user doesn't interact with the page for a day or a long time, the view state on server will expire. When the user posts back the page later, an exception is thrown.
For instance I watch youtube video of length 40 minutes. Yesterday I watched the first half, didn't close the tab but hiberated my computer. Today I continue watchig the last half, and post back something, the page will get errored out if the view state is in server and expired.
What is output caching for a web application, is it always good to use output caching to improve web app's performance. Besides output caching, are there some other caching techniques?
Output caching stores a rendered page/control and spits back the stored HTML instead of having to generate it again for each request. Typically you do output caching for a specified period of time, for example 60 seconds.
On the first request, the output is cached, subsequent requests for the 60 second duration use the cached page instead of generating the html again. If this control is database intensive, then all subsequent requests for the 60 second duration saved database calls, etc, and the page load for the subsequent requests should be much faster.
Information on Output Caching is readily available on google.
Other caching techniques would include, but is definitely not limited to:
Browser Caching
Object Caching
Query Caching
Have a read of this:
http://msdn.microsoft.com/en-us/library/aa478965.aspx
What is the difference between property Cache and OutputCache directive?
Cache is where you can put data - stuff coming from the database, or as the result of an expensive calculation, for example. Anything in cache should be available to all users.
OutputCache caches HTML - an entire page, or the output from a user control.
I suppose you can make a desition in your deep heart that both of them are different.
Most of time the Cache is used as the data or business result store. So you could only process your business logic or against your DB at the first time. You'll find it's very efficient one the process need much time. You can use it in your layers: data lay, business lay and so on.
OutPutCache: It announce the IIS server, proxy, or client to cache the response result. Especially benefit for the dynamic pages. The server will response the cached result to the client once it requested before.
I have a user control in my page which is inside a update panel.By using the user control i am displaying a message for the user.I need to change the message every 5 min.The message is stored in the data base and the user control will retrieve the message from the database every 5 min once automatically.
My problem is when there are more than 50 users accessing the same page then for every 5 min the request is sent from each client automatically to the server which decreases the server performance.
So can anybody help me to resolve this performance issue.
Make use of the Cache object in the UI tier to load in the different texts. Only load it in on first request when needed.
have a user control in my page which is inside a update panel
Try to get rid of the updatepanel as it will always send back and forth the full viewstate of the page. Make use of ajax, script only instead in combination with a PageMethod or a service endpoint (.asmx or wcf).
Also measure where things are going slow. I like to use tools like YSlow and Sql Profiler to measure. ASP.NET also has the capability of tracing which you can turn on/off in the web.config.
Requests to server will always use up resources. It's a fact of life.
You don't say which server it is that has the performance problem, but if the message in the database is static, then why not load it into a cache on the application server so that each client doesn't make a request to the database?
You need to profile your application to find the performance bottleneck(s).
Seriously! Anything else is just guessing.
Even though it did not top the list, I recommend the EQATEC Profiler.
Update
Just thought I would point out that 50 concurrent users should be no problem for ASP.NET.
MySpace runs on ASP.NET with 2.3 million concurrent users and handles 1.5 billion page views every day.
I have written an HttpModule that accepts the request, processes it (via a database lookup), and outputs results (html) back to the response. (Note that the HttpModule actually ends the request after it is done, so there is no normal ASP.NET processing of the request.)
As the database lookup can be expensive/time-consuming, I would like to store the results in-memory so that subsequent (identical) requests can be served the same content without going to the database.
Where can I store (in-memory) data so that it is available for subsequent invocations of the HttpModule?
You could store it in the Application.Cache, the result would be available Application wide then. Be sure to check for "new data" every now and then if necessary.
How is response size compared to your data fetched from db? What about rendering once you have that data in memory? If rendering is not an issue, I would just cache the data and render it on each request. If rendering takes lots of cpu, then you should cache the full response and directly serve it from cache.