Thursday 18 October 2007
Performance & Criticisms of ASP.Net
Performance of ASP.Net ASP.NET aims for performance benefits over other script-based technologies (including ASP Classic) by compiling the server-side code to one or more DLL files on the web server. This compilation happens automatically the first time a page is requested (which means the developer need not perform a separate compilation step for pages). This feature provides the ease of development offered by scripting languages with the performance benefits of a compiled binary. However, the compilation might cause a noticeable delay to the web user when the newly-edited page is first requested from the web server. The ASPX and other resource files are placed in a virtual host on an Internet Information Services (or other compatible ASP.NET servers; see Other Implementations, below). The first time a client requests a page, the .NET framework parses and compiles the file(s) into a .NET assembly and sends the response; subsequent requests are served from the dll files. By default ASP.NET will compile the entire site in batches of 1000 files upon first request. If the compilation delay is causing problems, the batch size or the compilation strategy may be tweaked. Developers can also choose to pre-compile their code before deployment, eliminating the need for just-in-time compilation in a production environment. Criticisms of ASP.NET Active Server Pages Classic (ASP) and ASP.NET can be run side-by-side in the same web application. This approach allows developers to migrate applications slowly instead of all at once. On IIS 6.0 and lower, pages written using different versions of the ASP framework can't share
without the use of third-party libraries. This criticism does not apply to ASP.NET and ASP applications running side by side on IIS 7. With IIS 7, modules may be run in an integrated pipeline that allows modules written in any language to be executed for any request.
In some cases ASP.NET runtime will recycle the worker process (e.g. if it becomes unresponsive or if an application runs amok and causes the worker process to use more than 60% of available RAM). It can also be configured to recycle the process proactively after a certain number of requests, time period etc. In these cases users may lose session state if the application is configured to use in-process sessions. If the application relies on session state to store authentication information (bad practice since cookie based authentication and membership is built into the framework) and the application is configured to use in-process sessions, the user may be logged out if the process is recycled.