How does output caching work in ASP.NET?
Output caching is a powerful technique that increases request/response throughput by caching the content generated from dynamic pages. Output caching is enabled by default, but output from any given response is not cached unless explicit action is taken to make the response cacheable.
To make a response eligible for output caching, it must have a valid expiration/validation policy and public cache visibility. This can be done using either the low-level
OutputCache API or the high-level
@ OutputCache directive. When output caching is enabled, an output cache entry is created on the first
GET request to the page. Subsequent
HEAD requests are served from the output cache entry until the cached request expires.
The output cache also supports variations of cached
POST name/value pairs.
The output cache respects the expiration and validation policies for pages. If a page is in the output cache and has been marked with an expiration policy that indicates that the page expires 60 minutes from the time it is cached, the page is removed from the output cache after 60 minutes. If another request is received after that time, the page code is executed and the page can be cached again. This type of expiration policy is called absolute expiration – a page is valid until a certain time.
What is connection pooling and how do you make your application use it?
Opening database connection is a time consuming operation.
Connection pooling increases the performance of the applications by reusing the active database connections instead of creating new connection for every request.
Connection pooling behaviour is controlled by the connection string parameters.
Following are the 4 parameters that control most of the connection pooling behaviour:
- Connect Timeout
- Max Pool Size
- Min Pool Size
What are different methods of session maintenance in ASP.NET?
There are three types:
- In-process storage
- Session State Service
- Microsoft SQL Server
The default location for session state storage is in the ASP.NET process itself.
Session State Service
As an alternative to using in-process storage for session state, ASP.NET provides the ASP.NET State Service. The State Service gives you an out-of-process alternative for storing session state that is not tied quite so closely to ASP. NET’s own process.
To use the State Service, you need to edit the
sessionState element in your ASP.NET application’s web.config file:
You’ll also need to start the ASP.NET State Service on the computer that you specified in the
stateConnectionString attribute. The .NET Framework installs this service, but by default it’s set to manual startup. If you’re going to depend on it for storing session state, you’ll want to change that to automatic startup by using the Services MMC plug-in in the Administrative Tools group.
If you make these changes, and then repeat the previous set of steps, you’ll see slightly different behavior: session state persists even if you recycle the ASP.NET process.
There are two main advantages to using the State Service. First, it is not running in the same process as ASP.NET, so a crash of ASP.NET will not destroy session information. Second, the
stateConnectionString that’s used to locate the State Service includes the TCP/IP address of the service, which need not be running on the same computer as ASP.NET. This allows you to share state information across a web garden (multiple processors on the same computer) or even across a web farm (multiple servers running the application). With the default in-process storage, you can’t share state information between multiple instances of your application.
The major disadvantage of using the State Service is that it’s an external process, rather than part of ASP.NET. That means that reading and writing session state is slower than it would be if you kept the state in-process. And, of course, it’s one more process that you need to manage. As an example of the extra effort that this can entail, there is a bug in the initial release of the State Service that allows a determined attacker to crash the ASP.NET process remotely. If you’re using the State Service to store session state, you should install the patch from Microsoft Security Bulletin MS02-66, or install SP2 for the .NET Framework.
What does the “EnableViewState” property do? Why would I want it on or off?
ViewState turns on the automatic state management feature that enables server controls to re-populate their values on a round trip without requiring you to write any code. This feature is not free however, since the state of a control is passed to and from the server in a hidden form field. You should be aware of when
ViewState is helping you and when it is not. For example, if you are binding a control to data on every round trip (as in the
datagrid example in tip #4), then you do not need the control to maintain its view state, since you will wipe out any re-populated data in any case.
ViewState is enabled for all server controls by default. To disable it, set the
EnableViewState property of the control to
What is the difference between Server.Transfer and Response.Redirect?
Why would I choose one over the other?
Server.Transfer(): client is shown as it is on the requesting page only, but all the content is of the requested page. Data can be persisted across the pages using
Context.Item collection, which is one of the best ways to transfer data from one page to another keeping the page state alive.
Response.Dedirect(): client know the physical location (page name and query string as well).
Context.Items loses the persistence when navigating to destination page. In earlier versions of IIS, if we wanted to send a user to a new Web page, the only option we had was
Response.Redirect. While this method does accomplish our goal, it has several important drawbacks. The biggest problem is that this method causes each page to be treated as a separate transaction. Besides making it difficult to maintain your transactional integrity,
Response.Redirect introduces some additional headaches. First, it prevents good encapsulation of code. Second, you lose access to all of the properties in the
Request object. Sure, there are workarounds, but they’re difficult. Finally,
Response.Redirect necessitates a round trip to the client, which, on high-volume sites, causes scalability problems. As you might suspect,
Server.Transfer fixes all of these problems. It does this by performing the transfer on the server without requiring a roundtrip to the client.