ASP.Net Website Optimization

Writing optimized website code is considered to be one the most complicated tasks. Hence, this paper unfolds some of the server-side parameter configuration techniques and various other improvements to boost your ASP.NET website's performance in the Internet Information Services (IIS) Web Server. The ASP.NET website goes live to the internet via IIS web server and typically, manipulates a huge amount of code and displays a large number of images and other graphics that obviously worsens the page retrieval time from the server and degrades the overall performance of a website. Hence, it is recommended to configure some of the parameters of IIS that effectively increase the overall performance of a website by retrieving an optimized web page to users.

HTTP Pages Headers

Every web page contains some auxiliary information in the form of a HTTP header that is sent to the server and used to inform the visitor web browser how to handle the web page during round tripping. The HTTP header assists to increase the performance of a web page through HTTP Keep-Alives and Content Expiration. The HTTP Keep-Alives setting is required for connection-base authentication such as IWA and the browser makes numerous connection requests for a web page in its absence and the website become less responsive and slower because the browser makes multiple requests to download an entire page that contains multiple elements. However, the HTTP Keep-Alives setting maintains the connection open for multiple requests.

On the other hand, we can reduce the second-access load time at a moderate percentage level through Content Expiration that determines whether or not to return a new version of the response to the request page if the request is made after the web page content has terminated. We can configure this property to every site through IIS as in the following:



                                                   Figure 1: HTTP Page Header

The HTTP header X-Powered-By ASP.NET is not required by the browser and should be removed because it is potentially exploitable and the website bandwidth usage is optimized to a small extent. Deletion such as headers remove unsolicited HTTP response headers from the header contents. Although, we can delete them using the URLRewriting and URLScan methods but IIS itself can remove them as in the following:



                                                            Figure 2: Response Header

Although, we can configure this setting by changing the web.config file directly from the Visual Studio side, by making the enableVersionHeader property set to false as in the following:

<system.web>
    <httpRuntime enableVersionHeader="false" />
</system.web>

HTTP Compression

The HTTP compression method requires support of HTTP 1.1 by the client browser, in which the website consumes less bandwidth and the page becomes more responsive because it compresses the data before the web server sends it and the browser decompresses the data before rendering it. This feature can be enabled in IIS through Windows Features as in the following:


                                                   Figure 3: IIS Features

The IIS Manager allows DEFLATE and GNU Zip compression schemes to compress application responses for both a dynamic application and a static file. It is beneficial in terms of increasing page response, improving bandwidth utilization and reducing server extensions. We can enable HTTP compression in the IIS web server as in the following. Here, we can decide the compression method along with other configuration rules such as cache directory and file size limit.



                                                   Figure 4: HTTP compression

Output Caching

Output caching makes web pages tremendously responsive during round-trips to the server. When a user requests a specific page, the web server returns it to the client browser and stores a copy of that processed web page in memory on the web server and returns it to the client in a subsequent request for that same content that eliminates the need to reprocess that page in the future.


                                                            Figure 5: Output Caching

But the cached contents are discarded if resources run low on the web server. Hence, the page will then be re-processed or re-cached at the time of the next request for that content. We can configure the cache size limit and maximum cached response size using the IIS manager as specified in the aforesaid image.

Website Connection

It is usually noticed that users do nothing after opening a website and keeps it open for an indefinite time, consuming the resources of the web server because IIS spends computing resources for keeping the connection alive. It is recommended to set a limit for opened web pages or to keep it as low as possible, to save computing resource and get better performance. We can set the connection time-out for a website in seconds through the IIS manager as in the following;


                                                      Figure 6: Connection Parameters

ASP.NET Debugging

Websites typically run in debugging mode during development, to do proper testing of business logic and other diagnostics, but unfortunately programmers forget to turn off this configuration during deployment on the production server that consumes abundant processing power and eventually degrades the performance. Debugging is disabled by default and although debugging is repeatedly enabled to troubleshoot a problem. The ASP.NET applications are compiled with extra information in debugging mode that enables a debugger to closely regulate and supervise the execution of a website. However, the performance of the application is affected. Deploying a website in enabled Debug mode is dangerous and reflected to be a huge vulnerability because hackers can obtain the inside information about the application. For that, they shouldn't have access indeed. We can configure this setting via the IIS manager as in the following:



                                                         Figure 7: Debugging options

We can also alter this setting from the web.config file by changing it to false as in the following:

<system.web>
   <compilation debug="false" explicit="true" strict="false" targetFramework="4.0" />
</system.web>

Bandwidth Adjusting

Bandwidth must be managed properly for a website because in the case of allotting a minimum amount of bandwidth to a specific website and a larger amount is required and on the other hand, a website using too much bandwidth whereas it is given shorter. Both scenarios would definitely affect the website performance. We can limit the total bandwidth for a website using the IIS manager that is disabled by default and is the recommend setting indeed.


                                                      Figure 8: Bandwidth Adjustment

Application Pool Limits

Websites can be divided into groups of one or more URLs that are served by a worker process. These pools create a complete sandbox isolation among the other application pools in which they are contained, offering security and performance benefits and cannot affect the applications in the application pool. Each application pool runs in their own worker process within the operating system so that there is complete isolation among pools. The w3wp.exe worker process runs in user mode and processes requests such as dynamic or static contents, for each application pool. Here, we can configure the application pool for a web server as in the following:



                                                            Figure 9: Pool Settings

When an application pool is recycled, the existing worker process is not immediately killed and instead, a second process is in progress and once it is ready, Http.sys will send all new requests to the new worker process. Once the old worker process has finalized all requests, it will shut down. So, we can stop such occurances by setting Disable Overlapped Recycle to false. Now the existing process will first shut down and then a new one will be started. We can do such configuration from Advanced Settings as the following:


                                    Figure 10: Recycling parameters

Unoccupied Modules

IIS deploys ASP.NET websites typically, containing built-in modules such as profile and passportauthentication that loads on each round trip to the server. Some of them are associated with that specific website to enable the corresponding functionality and the rest are useless, that creates an extra CPU overhead because they also load for each page request to the server. We can look at all the built-in modules using the IIS manger as in the following:



                                                Figure 11: unoccupied modules

We can either remove an unoccupied module using the IIS manger as illustrated in the aforesaid figure or on the web.config file in the project solution as in the following:

<system.webServer>
   <modules>
      <remove name="Profile" />
   </modules>
</system.webServer>

Summary

Although performance issues among websites is considred to be complicated and programmers have been striving to achieve fast responsive websites using sophisticated algorithms, but here we are achieving this not by writing code, rather just by making some configuration in the IIS web server indeed. We have come to an understanding of the performance internals of ASP.NET websites. In fact, we have touched the most crucial segment that is responsible for making a website good or worse in terms of performance. This article illustrates various IIS configurations of ASP.NET websites in the IIS web server, to make them faster and responsive.