A Brief History of Time

We've always talked about our hardware upgrades and how well they perform. Our hardware architecture is, no doubt, critical to the success of the site, but the software that actually runs AnandTech.com is equally important. Recently, we performed a major architecture shift from a ColdFusion based back-end to Microsoft.NET. We thought that this would be an interesting article, to highlight the history of AnandTech.com from a software perspective.

In this article, we will discuss background information on the following platforms:

ColdFusion

Macromedia ColdFusion is a web-based language that focuses on the RAD development of dynamic web content. ColdFusion started off based on a C++ runtime that interpreted code within HTML templates and compiled it into PCODE, which was then interpreted by the ColdFusion runtime and delivered to the web server and, in turn, to the end user requesting the page. ColdFusion back then was similar to PHP and ASP. Recently, Macromedia decided to take the ColdFusion language to a standards based platform, JAVA. ColdFusion runs on top of almost any J2EE server; we used the ColdFusion standalone version, which uses Macromedia JRUN as the J2EE server. ColdFusion templates are written in CFML (ColdFusion Markup Language) and then compiled down to JAVA byte code and executed by the J2EE server. Macromedia used to be the only game in town, in terms of ColdFusion. Now, a company named New Atlanta makes a ColdFusion server that also runs on .NET.

Microsoft .NET

The .NET platform is the new framework for building Windows based and web-based applications from Microsoft. It not only replaces the older ASP platform, but introduces some up-to-date languages that run on the Common Language Runtime, which is the backbone of .NET. The three main languages used with .NET are: C# (similar to C++), VB.NET (somewhat similar to VB) and J# (fairly close to JAVA). The beauty of this architecture is that it brings different developers together on a single platform. Those who wrote mostly in C++ or JAVA will probably choose C#; and those who are familiar with VB or more verbose languages will probably choose VB.NET. J# is there for the JAVA developer. Whatever language in which you write your code, it is compiled into an intermediate language, CIL (Common Intermediate Language), which is then managed and executed by the CLR. ASP.NET is simply another .NET based environment that allows you to write in any of the languages that run on the CLR. Its syntax is similar to ASP.

AnandTech 1.0

As most of you know, AnandTech started out as a static HTML site, hosted on GeoCities. Static driven sites are simply HTML based with the content contained within; dynamic driven sites fetch their content from external sources (usually database servers). Back then, static sites were quite popular while dynamic driven web sites were really just starting to catch on. In 1998, at Comdex, we laid out the first dynamic version of AnandTech.com. We decided on Oracle 8i as the database server, and ColdFusion 4.0.1 as the application server. We ran Oracle 8i and ColdFusion on two separate Sun Enterprise servers. We had no issues with Solaris or Oracle, performance-wise, but ColdFusion talking to Oracle was another story.

We developed a fairly simple content management solution that allowed us to post content through web forms. This approach to publishing saved a lot of time as content and the editorial staff grew. Articles could be posted from anywhere, and they could updated or removed at will by using our forms-based interface to the database. At that time, the content management engine was not feature-rich; it performed just the basic tasks necessary for the small editorial staff that we had.

The first version of the site was probably the most problematic version of the website (go figure), and the most difficult to maintain. Oracle is a powerful database server, without a doubt, but it lacks the finesse of Microsoft SQL Server and other database servers to some extent. The management UI leaves much to be desired (it doesn't hold a candle to SQL Server Enterprise Manager), and the language, although powerful, is not for everyone.

For ColdFusion to talk to Oracle, we had to use the Oracle Native drivers, which caused us a fair bit of grief and wasted time, as the SQL syntax had to be compatible with Oracle. When the development team consisted (and still consists) of one developer, time is critical. Speaking as the developer, I come from a SQL Server/Sybase world and while it isn't hard to pick up on Oracle's syntax, it is entirely too painful to use when time is so critical, especially when working with dates. Aside from the pain of the syntax, the native drivers also caused some anguish in ColdFusion. ColdFusion was crashing occasionally and caused some unnecessary administrative headaches that needed to be rectified each time it went down. By this time (about a year or less later), it was time to move on to something more stable.

Hardware used in version 1.0
Sun Enterprise 250 w/ 512MB Memory

View version 1.0 of the website

AnandTech 2.0

We decided that Solaris and Oracle were not for us. Not because either one was slow, but simply because the combination of ColdFusion and Oracle was not working out for us. Yes, we could have gone with another language, but we weren't very fond of the choices at that time, and our expertise was in ColdFusion.

After doing some basic mock ups and tests, we ended up using Windows NT 4.0 and ColdFusion 4.5.1 SP2, which was rock solid for us. The content management solution didn't change much in this release of the site; we just spent some time re-writing some of our SQL to optimize it for the SQL Server platform.

Our site, and sites like ours, rely on advertising revenue to keep it alive. We had been using Ad Juggler for awhile (a Perl based package at the time) and it was starting to show its weakness as load was increasing. We decided to go with a ColdFusion based package called FuseAds, which we still use to date.

Hardware used in version 2.0
Dual Intel Pentium III Xeon 500 w/1MB L2 Cache and 1GB of memory.

View version 2.0 of the website

AnandTech 3.0

Just like our hardware coverage, our infrastructure is current. Windows 2000 was released and was miles ahead of NT4 in terms of manageability and stability. We waited until Service Pack 1 was released, and then upgraded the servers at approximately the same time when Macromedia acquired Allaire (the makers of ColdFusion), and released ColdFusion 5, which included some serious performance increases and stability improvements. The upgrade went well, and again, we had no issues with the site or the back-end.

Since the beginning, we had been using Mediahouse Live Statistics Server to analyze our web logs. We were generating nearly 1GB of logs per server, and we were starting to experience some problems with Statistics Server because of the amount of logs being analyzed. We decided to switch to analog, and write a web-based front end to it. We would analyze the logs into a data file and put it in our database for easier manipulation. This system worked quite well for some time, until our log files became unmanageable.

Bandwidth during this period of our growth was fairly expensive, and was starting to cost us significant amount of money to maintain. The HTTP 1.1 protocol had included an innovation called HTTP Compression. Since it had been out for awhile and was supported by over 90% of our readers browsers, we decided to implement it. We cut our bandwidth in half, which, needless to say, had cut our expenses by a significant amount. This version of the website was the longest running version.

Hardware used in version 3.0
5 x Dual AMD Athlon Thunderbird 1GHz w/ 768MB of memory

View version 3.0 of the website

AnandTech 4.0

This release of the site was a fairly major upgrade in terms of back-end code. We decided to do a rewrite on the site code, which we have been using since version 2.0. ColdFusion MX had been released, and AnandTech was used as a high load test site during the beta of ColdFusion MX. Needless to say, we beat on it and found a few issues here and there that were fixed prior to MX's release. One of the significant changes in the ColdFusion language was the ability to form code components into a web-based API, which really helped us organize the code into more reusable sections.

Reporting of web statistics was starting to cause us some grief in this release due to the amount of clustered servers and log file size. We obtained a quote from WebTrends for their software, but it was going to cost around $15,000 for our server farm. We felt that analyzing log files was archaic, and we decided to make our own statistics tracking system. Development of the web statistics system took a couple of weeks, and is the same system that we use to date.

Just as our traffic was increasing, so was the size of our editoral staff, and the amount of content being published. Anand and the other editors asked for an easier way to create their graphs; basically, a central system to manage the data that goes in the graphs and to be able to re-generate them without having to upload images. So, we did some research and found a fantastic piece of software called SwiffChart from GlobFX, a company in France. This graphing engine allowed us to construct our graphs programmatically from our content management system. SwiffChart gave us a number of file formats in which to save the generated graphs. We had originally used Flash because of its file size when compressed (smaller than any other conventional format). We recently switched to PNG format, the next smallest format due to the number of readers who can't have the plugin or want it for that matter. To date, we still use this graphing system, although it has been enhanced over the past year with various features to make it even easier for our editorial staff to use.

During this release, we had a few issues with the Windows version of Apache, which we used because of mod_gzip (HTTP Compression) module. Apache wasn't threading properly on Windows at that time (prior to version 2 of Apache). We decided to switch to IIS, and a HTTP compression module called PipeBoost, which we still use now. The next upgrade was the largest in the history of the site.

Hardware used in version 4.0
5 x Dual AMD Athlon MP 1900+ w/ 512MB Memory

View version 4.0 of the website

AnandTech 5.0

After 5 years on the ColdFusion platform, the time had come to move on to what we think is a better platform for the future of the site - Microsoft .NET. The decision to move away from ColdFusion was a tough one in some ways. ColdFusion offers a tremendous advantage over other languages, thanks to its RAD (Rapid Application Development) roots, but the trade offs were cost and stability. Cost was definitely the major factor in our decision. Our server platform is standardized on Microsoft Windows, so .NET is free for us, while ColdFusion costs us $1299 USD per server. As we continue to grow, and keep up with the newer versions, the costs rise. One could argue that we would make up for those costs with the time that ColdFusion saves the developer. However, we found that not to be the case, and we'll explain why later.

We did quite a bit of testing prior to beginning development, writing a skeleton framework and load testing it and comparing the results to ColdFusion. The results were attractive with .NET definitely, offering some serious performance gains (more to follow on our benchmark results). The architecture of the new AnandTech.com site consists of a VB.NET API behind the ASP.NET user interface; the API can be exposed as a web service with the flick of a switch, if necessary. We chose VB as it is a more natural progression from ColdFusion syntax, and offers the same performance and features as C# does. VB.NET is a completely different animal than VB; although the syntax may be similar in some ways, it offers a heck of a lot more than VB ever did.

Writing the API is what took the most time, as we had to port over our back-end framework from ColdFusion into our new VB.NET API. Our first step was to write a few functions that handled some of the tedious work in writing any web application: a database class that handles all the database calls, which reduces the amount of lines of code we had to write for each call; a few list functions; and, some other little functions that ColdFusion had built in. Those functions took a few hours at most to write, and covered the main functions that we had taken for granted in ColdFusion. After those functions were written, we found that the RAD argument started to diminish, especially with the slick IDE that Microsoft offers. Visual Studio .NET is, bar none, the best IDE that we've seen. It offers a robust development environment with extensive function insight features, which really speed up the development process. If Macromedia were to develop this kind of IDE for ColdFusion, I think the differences between the two platforms would most definitely start to diminish.

The next major piece of work that we did was to transition the interface from HTML to CSS. This was a major undertaking, but once the framework was complete, the rest just fell into place. The old site was all HTML, and had a few too many tables in it. The result was a slower rendering site, and combined with the ads, it only made the situation worse. As a result, we took a 130K site down to around 45K in HTML. Needless to say, the page rendering times are night and day in comparison.

Hardware used in version 5.0
5 x Dual AMD Athlon MP 1900+ w/ 1GB Memory

So, after we were finished, how does it perform? Take a look below.

Note: These benchmarks compare the old anandtech site to the new anandtech site, not ColdFusion to .NET. There were many changes that resulted in the performance increase, the platform was just one of them.


The graph above depcits how many requests per second the server was handling during the load test.

The graph above depicts how long the site takes (under load) to deliver the last byte to the client.

Conclusion

As you can see, the new site was a technical success for us. As always, there was feedback after the initial launch, and we addressed most of the comments. We've come a long way from the day of our first dynamic site, and have learned more in 3-4 years than some people do in their entire career. So what's next? Well, 64-bit is certainly on the horizon; we already have a 64-bit platform in production that is performing incredibly well. We'll have an article in the near future on how our quad Opteron performed in comparison to our older platform. For now, it's back to building a better AnandTech; it never ends...