Tag Archives: ASP.NET

IIS 7.5: Avoid performance issues when creating isolated application pools for applications

At NowOnline, we recently experienced major performance problems with two of our webservers (Windows 2008 Web Server with IIS7.5). Over the months memory consumption and CPU usage had increased substantially as the number of hosting packages increased to respectively 290 and 120 websites. As a result, websites running on these machines became progressively slower. Worse, the dreaded ‘Out of memory’ exception started showing up periodically as the servers tried to free and allocate RAM to new worker processes. Adding additional RAM to the virtual machines did remedy the problems for a while, but this was not a permanent solution.

Our hosting provider diagnosed the problem initially and attributed it to the sourcecode and the volume of websites (and suggested adding more RAM). So I set out to figure out what was going wrong, really. I initially explored potential memory leaks or bad code but was unable to find a clear pattern here. Some of the larger sites used more memory, obviously. But I couldn’t find clear examples of the telltale sign of memory leaks; an ever increasing memory consumption by a single website. Next, we started moving websites to another webserver to test if the problem was caused by the load of the increasing pool of websites. Turning off some heavy websites did not improve performance and did not reduce memory load significantly. Any freed up RAM was quickly used up by other websites.

A major part of the solution turned out to be in the way we used application pools. When configuring the webservers I had always adhered to the ‘best practice’ of creating a separate application pool per production site (see this article, for example). This is actually the default behavior when creating a new website in IIS. There are clear advantages to this approach:

  • If a code problem causes the website to crash (i.e. infinite loop or a memory leak), only the associated application pool crashes. This means that other websites are not affected by problems in other websites;
  • This approach makes it easier to tweak application pool settings (CPU and RAM allocation) for specific websites;
  • It is easier to diagnose memory leaks by investigating RAM usage by a single application pool;

IIS is quite clever when it comes to managing the application pools. If a website is not getting any traffic for a while, IIS shuts down the associated application pool by default. This frees up resources (RAM and CPU) for other application pools. Should a new visitor arrive, IIS simply starts up the application pool and spawns worker processes. It soon dawned on me that every application pool requires some overhead in resources. And RAM that was allocated to one pool could not be freely used by another pool.

To test if our configuration (one application pool per website) was indeed causing the problems, I started grouping the websites into several shared application pools based on their logical relatedness and .NET framework. For the more critical websites, I decided to stick to isolated application pools just to be sure. I ended up going from 250 pools to about 20. The results speak for themselves:


Picture 1: Memory consumption by alpha-web1 before and after the change (around 4PM)


Picture 2: Memory consumption by alpha-web2 before and after the change (between 7 and 8.30PM)

The results clearly show that RAM consumption dropped dramatically, from a structural 98% to around 45%. The virtual memory (‘Swap’ in the picture) that had to made available to virtually increase RAM also dropped to zero, which had the nice side effect of lowering Disk I/O. Not only had the servers become significantly more responsive, performance for individual websites also increased.

We initially worried about strange behavior, such as duplicate MVC route names, caching conflicts and such, but experienced none of these. IIS does isolate this kind of behavior nicely.

The lesson that I learned from this is that it’s not a good idea to stick too rigidly to a ‘application pool per website’ practice. Instead, try grouping non-critical websites into shared application pools as much as possible, unless you run into problems. If you have a critical production website, creating a separate application pool is still the best possible advice though. I hope this post will be of help to other administrators struggling with similar performance issues.

via: http://www.christiaanverwijs.nl/post/2013/08/28/IIS-75-Avoid-performance-issues-when-creating-isolated-application-pools-for-applications4.aspx

Best practices for creating websites in IIS 6.0

Every time I create an IIS website, I do some steps, which I consider as best practice for creating any IIS website for better performance, maintainability, and scalability. Here’ re the things I do:

Create a separate application pool for each web application

I always create separate app pool for each web app because I can select different schedule for app pool recycle. Some heavy traffic websites have long recycle schedule where low traffic websites have short recycle schedule to save memory. Moreover, I can choose different number of processes served by the app pool. Applications that are made for web garden mode can benefit from multiple process where applications that use in-process session, in memory cache needs to have single process serving the app pool. Hosting all my application under the DefaultAppPool does not give me the flexibility to control these per site.

The more app pool you create, the more ASP.NET threads you make available to your application. Each w3wp.exe has it’s own thread pool. So, if some application is congesting particular w3wp.exe process, other applications can run happily on their separate w3wp.exe instance, running under separate app pool. Each app pool hosts its own w3wp.exe instance.

So, my rule of thumb: Always create new app pool for new web applications and name the app pool based on the site’s domain name or some internal name that makes sense. For example, if you are creating a new website alzabir.com, name the app pool alzabir.com to easily identify it.

Another best practice: Disable the DefaultAppPool so that you don’t mistakenly keep adding sites to DefaultAppPool.

image

First you create a new application pool. Then you create a new Website or Virtual Directory, go to Properties -> Home Directory tab -> Select the new app pool.

image

Customize Website properties for performance, scalability and maintainability

First you map the right host headers to your website. In order to do this, go to WebSite tab and click on “Advanced” button. Add mapping for both domain.com andwww.domain.com. Most of the time, people forget to map the domain.com. Thus many visitors skip typing the www prefix and get no page served.

image

Next turn on some log entries:

image

These are very handy for analysis. If you want to measure your bandwidth consumption for specific sites, you need the Bytes Sent. If you want to measure the execution time of different pages and find out the slow running pages, you need Time Taken. If you want to measure unique and returning visitors, you need the Cookie. If you need to know who is sending you most traffic – search engines or some websites, you need the Referer. Once these entries are turned on, you can use variety of Log Analysis tools to do the analysis. For example, open source AWStats.

But if you are using Google Analytics or something else, you should have these turned off, especially the Cookie and Referer because they take quite some space on the log. If you are using ASP.NET Forms Authentication, the gigantic cookie coming with every request will produce gigabytes of logs per week if you have a medium traffic website.

image

This is kinda no brainer. I add Default.aspx as the default content page so that, when visitors hit the site without any .aspx page name, e.g. alzabir.com, they get the default.aspx served.

image

Things I do here:

  • Turn on Content Expiration. This makes static files remain in browser cache for 30 days and browser serves the files from its own cache instead of hitting the server. As a result, when your users revisit, they don’t download all the static files like images, javascripts, css files again and again. This one setting significantly improves your site’s performance.
  • Remove the X-Powered-By: ASP.NET header. You really don’t need it unless you want to attach Visual Studio Remote Debugger to your IIS. Otherwise, it’s just sending 21 bytes on every response.
  • Add “From” header and set the server name. I do this on each webserver and specify different names on each box. It’s handy to see from which servers requests are being served. When you are trying to troubleshoot load balancing issues, it comes handy to see if a particular server is sending requests.

image

I set the 404 handler to some ASPX so that I can show some custom error message. There’s a 404.aspx which shows some nice friendly message and suggests some other pages that user can visit. However, another reason to use this custom mapping is to serve extensionless URL from IIS. Read this blog post for details.

image

Make sure to set ASP.NET 2.0 for your ASP.NET 2.0, 3.0 and 3.5 websites.

Finally, you must, I repeat you “MUST” turn on IIS 6.0 gzip compression. This turns on the Volkswagen V8 engine that is built into IIS to make your site screaming fast.

via: http://msmvps.com/blogs/omar/archive/2008/10/04/best-practices-for-creating-websites-in-iis-6-0.aspx

ASP.net MVC Vs ASP.net Web Form

Software Architects have been involving lot of debates about different approaches and architectures. Some of the examples are ORM Vs Store Procedures, REST Vs SOAP, etc. There is a debate happening inside the Microsoft community about ASP.net web form Vs ASP.net MVC. Many people thinking that ASP.net MVC will be replace webforms at least eventually and others are thinking that ASP.net MVC will not be replace webforms. Will ASP.net MVC replace webforms?. ASP.net MVC is an alternative approach to webforms rather than a replacement. It will not replace webforms and webforms will not replace ASP.NET MVC. The fact is that ASP.NET MVC and webforms will co-exist and that ASP.NET MVC is not a replacement for webforms. If you prefer ASP.net MVC use it and you feel webform is more comfortable, you can use it. . Both approaches are just choices and different approaches and choices are good things. Different choices are available for other platforms especially in the Java platform.

Problems with ASP.net Web Form

What are the problems with webforms? In webforms, Microsoft has tried to make windows form model development for web application development. That model was attracted lot of windows form developers especially VB 6.0 developers. Many of VB 6.0 developers had moved to ASP.net web development without knowing the basics of HTTP and web. For simulating windows form model development experience, webforms introduced event-driven approach and also introduced Viewstate and Postback. The end result is that web forms breaks the stateless nature of the Web. Both Viewstate and Postbacks have been made lot of problems and increased complexity of the web application development. Many web pages having hundreds of KB size of Viewstate that affected the performance of the applications sometime. Developers do not have the control of the rendering HTML of web forms and Server controls that render html with mixed inline style and deprecated tags that does not follows standards. Another problem with Web Forms is the integration of JavaScript frameworks due to the naming conventions of rendered HTML. The page life cycle of the Web Form is too complex and has the tightly coupling between all things in the ASP.net framework and a single class is used both to display output and handles user input. So unit testing is almost an impossible task. Today unit testing is very important in modern software development especially when we following agile methodologies and practices. Since web is a stateless thing, Events, Postbacks and Viewstate are not a good way. Today many ASP.net web form developers are facing different type pf browser compatibility issues when developing public face internet applications

The ASP.net MVC way

The ASP.NET MVC simplifies the complex parts of ASP.net Web Forms without any compromise of the power and flexibility of ASP.NET platform. ASP.net MVC implements Model-View-Controller UI pattern for web application development that lets you allows to develop applications in a loosely couples manner. MVC pattern is separating the application in three parts- Model, View and Controller. A view is responsible for rendering the user interface (UI) of the application and it is nothing more than html templates that filled with application’s data passed by the controller. The Model implements the logic for the application’s data and it represents the business objects of the application that using the View for rendering user interface. Controllers are handles and responds to user input and interaction. The web request will be handled by the controller, and the controller will decide which model objects to use and which view objects to render. The MVC model replaces the Web Form events with the controller actions. The main advantages of the MVC models are clear separation of concerns, unit testing facility, and more control over the URLs and HTML. The MVC model does not use Viewstate, Postbacks, Server controls, and server-based forms that enable full control over the application and html rendered by the Views. MVC model is using Representational state transfer (REST) based URLs instead of file-name extensions used by the Web Form model so that we can make search engine optimization (SEO) URLs published by the application.

The below code shows the implementation of MVC application.

ProductsController.cs (Controller)

 


In this sample, I have used extension methods to the HtmlHelper class to display ordered list of information.

OrderListExtensions.cs


Category.aspx (View)

Advantages of MVC Model

  1. Enable clean separation of concerns (SoC) .
  2. Enable full control over the rendered HTML.
  3. Enable Test Driven Development (TDD) (built with TDD in mind).
  4. SEO and REST friendly URL.
  5. Easy integration with JavaScript frameworks.
  6. Support third-party view engines such as NVelocity, Brail, NHaml.
  7. No ViewState and PostBack events.
  8. Follows the stateless nature of web.
  9. Extensible and Pluggable framework.
  10. Ideal platform for Web 2.0 applications.

Advantages of Web Form Model

  1. Provides RAD development.
  2. Easy development model for heavy data-driven LOB applications.
  3. Provides rich controls.
  4. Familiar model for windows form developers.

Which is the best approach?

The choice would be vary on different people. If you want more control over the HTML or you want Test Driven Development (TDD), or you care about web standards, accessibility, or you want to build SEO based URLs, you can choose MVC model. If you want rich controls and state oriented event-driven web development, you can choose Web Forms model. If you feel more comfortable with MVC, choose that model and you feel Web Form model is more comfortable, choose that model. Both are just choices. If you start your career with ASP.net Web Forms and do not have full knowledge of Web, it will be very difficult moving to MVC model.

I prefer MVC over Web Forms and I feel that Microsoft is going to a right direction through MVC. Its technical features as well as the open source nature are attracted me a lot.The MVC model allows me full control over the HTML and enables Test Driven Development (TDD). We can easily integrate with jQuery and other JavaScript frameworks with MVC. Using extension methods of C# 3.0, we can make powerful and rich HTML helper methods. I believe that tesatbility, refactoring capability and maintainability are the main factors for a successful project and prefer these factors than RAD capability. The MVC model allows to build highly testable, maintainable loosely coupled applications with good practices such as TDD, Seperation of Concerns (SoC) and Dependency Injection (DI). You MUST use ASP.NET MVC for public face internet applications.

via: http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx