In a previous article about our migration, we discussed briefly what we did to move to ASP.NET. In this edition, we'll go into a bit more detail specifically on the development side.

AnandTech consists of a few different applications that make the entire site operate. The main website ( serves the articles that we write - this was the first application that we migrated. The migration of the main website was fairly straightforward; we simply ported our ColdFusion code into ASP.NET, learning new syntax as we went. We made use of the code-behind techniques for which ASP.NET is known as we ported parts of the application. And, we wrote a web API similar to our old ColdFusion site to handle back-end logic. Each time that a request begins, we have an init class, which handles instantiating the framework for the page request. The page inherits the web-based API and can then execute methods for the various operations in the pages. This is not much different than most web-based applications of this size.

One thing that we took for granted in our old ColdFusion website was debugging output. ColdFusion has a fairly unique feature that allows you to expose debugging output for a page request. This output consists of the various web-based variables, form, URL and the contents of cookies. It also outputs the SQL syntax submitted to the RDBMS and the various method calls made to any functions in the application. This type of debugging output is extremely helpful when troubleshooting a problem or even when tuning an application, as you can see clearly what the page is doing and how long it's taking to perform each individual method call or query to the database.

So, during our development of the API, we wrote a debug class, which tied into our database class and the OnRequestEnd event from the Global.asax part of the .NET framework. Essentially, it tracked query calls and variables and outputted the data in the OnRequestEnd event of the page request.

Index Our bread and butter is up next


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. Reply
  • 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? Reply
  • 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? Reply
  • ncage - Monday, November 29, 2004 - link

    Awesome it looks like 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. Reply
  • 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. Reply
  • 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