Scalability of the website

Since the site went live with the new ASP.NET framework, we've constantly been monitoring the servers and tracking statistics, and to say that we've been impressed is an understatement. We've had near 99% up-time and have seen dramatic increases in performance and scalability of the site infrastructure. Each of our clustered servers use an average of 12% CPU, and each server has at least 450 users on them at any given time. Pages execute in an average of 15ms, which is 60-80ms better than what we used to do.

To track our statistics, we wrote a performance counter monitor that resides on each server. It essentially writes the output of various performance counters to an aspx page, which we then feed into a database and run reports, view trends and monitor new versions of the site code as they are put into play.

Last week, we performed a test on scalability, to see how scalable one server was in the cluster. We monitored a server in the cluster for a period of 10 minutes while all five servers were in the web cluster. Next, we shut off four of the servers leaving one to serve the load for the website. Below is a table of the before and after of this test - impressive results in our opinion.

 Performance Counter  Before
(5 servers in the cluster)
 After
(1 server in the cluster)
CPU Usage 5% 30%
Concurrent Users 450 2400
Requests per second 12 80
Average request time (ms) 15 18

As you can see, ASP.NET is very efficient. CPU usage climbed to 30%, not much considering nearly 2000 more users were on the server. Request per second were 7 times higher and our average page request times were still approximately the same, showing the efficiency of the ASP.NET runtime and the scalability of the website itself.

The migration has been successful, but there is always something else to do with a site of this size. We have a meeting at CES in January to talk about future plans. There will be, more than likely, new functionality to plan for and architect (what I live for). We're also going to take a look at a possible firewall upgrade next year. We've managed to hit our 18,000 simultaneous sessions limit twice in the past few months; once, we sustained 65Mbit/second of throughput for a few hours.

The Forums get migrated
Comments Locked

26 Comments

View All Comments

  • everman - Tuesday, November 30, 2004 - link

    Do you have any specific measures built in to handle something such as a slashdotting? Such as a page with lower bandwith requirements (static page with no database queries). Maybe actually be able to dynamically create such a page if it goes over a certain number of requests in a time period.
  • Phiro - Tuesday, November 30, 2004 - link

    You cluster for several reasons; peak load (aka slashdot effect), high availability for hardware failure reasons and for maintenance reasons, i.e. a MS security patch. Or power cabling changes in their server room. They can take 1/2 the cluster down (for instance) and do whatever needs to be done, then swap, rinse, and repeat as neccessary.

  • mldeveloper - Monday, November 29, 2004 - link

    Jason, can you comment on the effect of a slashdotting? Is this one of the reasons you are running a cluster if normal traffic can easily be handled by one server?
  • Jason Clark - Monday, November 29, 2004 - link

    #21, there are tests that state that PHP5 is faster, then others state ASP.NET is faster. I have yet to see a well written and fair test. We prefer ASP.NET, it suits our needs.

    #22 We use Microsoft SQL Server 2000 Enterprise.
  • hifisoftware - Monday, November 29, 2004 - link

    Nice article. Can you tell us which Db are you using?
  • ncage - Monday, November 29, 2004 - link

    Awesome it looks like asp.net has awesome performance. Looks like microsoft did a good job. What i would be interesting in finding out is how it compares in perfomance to PHP. Maybe im wrong but i don't think a "huge" amount of sites use cold fusion a lot of them use PHP or classic asp pages.
  • Jason Clark - Sunday, November 28, 2004 - link

    #15 I agree, we'll work on putting more on a page, it is annoying.

    #16 I took alook at the tracing namespace, I guess not close enough. From what I see it does some of what we need but not the sql syntax passed to ado, which is probably the most valuable part of our debugging class.

    #18, we're working on the flash ad issues, i hear ya.

    #19 the quad 848 is our db server, all our webservers are still dual athon MP's :)
  • Jeff7181 - Sunday, November 28, 2004 - link

    Pay no attention to #3&4, Jason. He's probably a THG regular over here trolling, lol.

    Seriously though... I love these articles... it's interesting to know what kind of hardware and internet connection and software is needed to run a site like this.

    Is this the same Quad Opteron 848 setup w/8 GB of RAM mentioned in a previous article?
  • elecrzy - Sunday, November 28, 2004 - link

    I was wondering if its possible for you to make the website more compatible with firefox since the ad flickering is really annoying.
  • Reflex - Sunday, November 28, 2004 - link

    11 - No, I mean compare it to a Apache/Linux based platform, as well as other options.

    Jason - You'd want to disclaimer such an article very heavily, and simply put it as your experience. I just know that right now it is virtually impossible to know what platform is going to give you more performance on the same hardware, all you can do is look at various marketing docs and hope your reading half the truth. There was a day where MS was not a serious player in this space, I am curious about how far they have really come. Real world info on that is more or less non existant.

Log in

Don't have an account? Sign up now