Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com 

March, 2010

  • Alik Levin's

    ASP.NET Performance: Get Rid of HTTP 401 and HTTP 304

    • 0 Comments
     Alik Levin    Making fewer calls to IIS web server improves your ASP.NET application’s performance, or more precisely, it improves UI responsiveness or, even more precisely, it improves UX, the User Experience. Better User Experience leads to better adoption. 

    Quick Resource Box

    In this post I will share how to improve User Experience by reducing the number of HTTP 401 and HTTP 304 responses.

    The Impact of HTTP 304

    In general HTTP 304 is returned by web server when the browser is not really sure about up-to-date’ness of the resource. Imagine this conversation:

    1. Browser: “Hey, IIS web server, I have this GIF file in my cache stored locally. I stored it here since my last visit to your page. Not sure it’s up-to-date. Should I use it? Or, do you have a newer version?”
    2. IIS web server: “HTTP 304. Nope, there is no newer version down here in the data center. Use your locally cached version of the GIF.”
    3. Browser displays the GIF from local cache.

    This one extra roundtrip might look very subtle in case when there are very few static elements on the page. In case there are many static elements on the page the User Experience can be severely affected. Below is an extreme example of HTTP 304 responses captured by Fiddler. All the images in the diagram are stored in local cache but they never displayed right away – Browser first consults with the server and gets HTTP 304 before displaying it:


    image

    The Impact of HTTP 401

    HTTP 401 returned when Browser requests a resource that requires authentication. The fact that the resource requires authentication results in two HTTP requests – initial requests gets HTTP 401 asking for credentials, and subsequent request is satisfied with the actual response after the creds were validated. Something similar to this:

    image 

    Imagine now situation that static resources such images, JavaScript, CSS files, etc require authentication. Usually these guys are the same for every user and there is no point to require authentication/authorization for it, right? If so then there is no need to waste another HTTP 401 roundtrip for them, right?

    Improve Performance by Partitioning Your Application

    Consider the following solution structure:

    image

    Notice the following four folders: CSS, IMG, JS, and Restricted. The first three contains static style sheets, images, and JavaScript files respectively. The Restricted folder contains all the dynamic ASPX pages that implement your scenarios referencing the static content from the other three folders when needed. The web.config file looks as follows:

    <?xml version="1.0"?>
    <configuration>
        <system.web>
          <authorization>
            <allow="*"/>
          </authorization>
        </system.web>
      <location path="Restricted">
        <system.web>
          <authorization>
            <deny="?"/>
          </authorization>
        </system.web>
      </location>
    </configuration>

    This configuration achieves the following:

    1. Static files served from publically accessible location that way we avoid HTTP 401 extra roundtrips.
    2. System administrators are not required to fish the static files across the solution’s file structure just to set expiration policy – there are only 3 folders to specify it so there is a better chance it will happen. It should help reducing HTTP 304 extra roundtrips.

    Related Books

  • Alik Levin's

    ASP.NET Performance: Web Application Gets Slow Periodically – IIS Recycles

    • 0 Comments

    A customer complained that his ASP.NET web application gets slow periodically. It happens at random times, the system just gets slow then after few minutes it gets back on track with normal response times.

    One of the reasons for such behavior is an AppPool default recycling policy set in IIS.

    Default AppPool Recycling Policy in IIS

    The default recycling policy for application application pool is 29 hours. Both IIS 6.0 and IIS 7.

    image

    It means that every 1740 minutes the application pool recycled. 1740 minutes means 29 hours. 29 hours means randomness.

    Correlate Event Logs and IIS Logs

    To make sure you are dealing with recycling (there are few more reasons I will be discussing in the next posts) one needs to correlate IIS recycle events in Windows Event log with slowness of the pages in IIS log.

    Start with Windows Event log. Go to System Event Log and filter events with W3SVC as a source. Look for recycle events with id of 1074:

    iis recycling event

    Notice the time the recycle occurred.

    Go to IIS logs and filter out the resources that took significantly long. One way to look into the IIS logs is using Excel as outlined here - Identify ASP.NET, Web Services, And WCF Performance Issues By Examining IIS Logs. Another way is using LogParser as outlined here (via Tess) - Using LogParser 2.2 to Parse IIS Logs and Other Logs.

    Notice time-taken is pretty lengthy, around 30 seconds. Notice the time it is taken. Now look at the times that the Event log captured 1074 events – it is 2 hours diff. It is because IIS logs events using GMT and Windows Event log is time zone sensitive. I live in GMT+2 time zone. So the times are correlated.

    image

    Recommendations

    Remove IIS recycling default policy. I once heard someone saying it is training wheels. If your app pretends to be stable then you do not need recycling at all – of any kind. Just remove it all. If you are using recycle there are potentially two reasons, actually one – you have problematic application that misbehaves. It’s either under your control to fix it by changing the code or out of your your control when you buy an app that you cannot fix. Ask for a fix from the vendor. It might be also a good time to review your capacity plan. In any case – recycling is a workaround and not the solution.

    Related Book

    My related posts

  • Alik Levin's

    Measuring ASP.NET Performance Using Counters

    • 0 Comments

    Following is a list of performance counters I am usually taking to spot low hanging fruits when measuring ASP.NET performance:

    Resource utilization

    \.Processor\%Processor Time
    \.NET CLR Memory(*)\Allocated Bytes/sec
    \.NET CLR Memory(*)\% Time in GC
    \.NET CLR Exceptions(*)\# of Exceps Thrown / sec
    \.NET CLR Loading(*)\Current Assemblies

    Throughput

    \.NET CLR LocksAndThreads(*)\Contention Rate / sec
    \.NET CLR LocksAndThreads(*)\Current Queue Length
    \ASP.NET\Requests Queued
    \ASP.NET\Request Wait Time
    \ASP.NET\Requests Current
    \ASP.NET Applications\Requests In Application Queue
    \ASP.NET Applications\Pipeline Instance Count
    \ASP.NET Applications\Requests Executing
    \ASP.NET Applications\Requests/Sec
    \Web Service\Current ISAPI Extension Requests

    Response time

    \ASP.NET\Request Execution Time

    SQL Server

    SQL Server: General Statistics\Logins/sec
    SQL Server: General Statistics\Logouts/sec
    SQL Server: General Statistics\User Connections

    Detailed explanation about each counter and its significance can be found here: Chapter 15 — Measuring .NET Application Performance

    I particularly love the following diagram from the guide. The diagram helps brainstorming while identifying root cause of the performance issues identified using the counters:

    clip_image001

    Related Book

    My Related Posts

Page 1 of 3 (8 items) 123