InfoWorld Redesign

By the time anyone reads this, InfoWorld will have launched a brand-new site, and a vastly-improved one, in my opinion.   You're seeing some of the work in the template of this weblog.  While you can enjoy the new UI and frontend functionality on your own, the backend changes might not be quite so noticeable.  During the frontend redesign, we also completely re-engineered the backend to provide better performance,  more stability, and a fiscally-responsible scaling model for InfoWorld.com.  A HUGE thanks is in order to the engineering and design team who pulled this off, working 90-hour weeks because they loved what they were doing (most of the time, anyway).  I can't possibly thank all of them enough or list all the amazing things they did, but what you see is largely due to the work of Derek Butcher, Chris Lin, Kevin Varley, Eric Hill, and Matt McAlister, as well as the patient editorial staff of InfoWorld, led by Kate McLucas and Kathy Badertscher.

Now, about the backend changes. . . . when I started at InfoWorld in April 2001, we had a mish-mash of Sun Solaris and Windows NT/2000 serving the site.  Managing a heterogeneous environment with a very small staff was difficult.  As a proponent of Linux in real production environments (since it was remarkable enough for a Linux implementation to be a standalone Slashdot story), I knew Linux was the ideal long-term platform for InfoWorld in a tough economic climate, so we dipped our toes into the Linux waters last year with a few server deployments.  As of the redesign launch, InfoWorld.com is now 100% Linux, running on inexpensive Compaq DL360s that perform like crazy (thanks to Wade Grubbs and Kevin Railsback of the InfoWorld IT staff, who built and configured all the machines and hauled them in the pouring rain from our SF offices down to San Jose). 

Not only have we completed our migration to Linux, we made some other key technology moves:

• Upgrade to Apache 2.0 -- every time I start to take Apache for granted, I seem to have a reason to fall in love again.  InfoWorld has a relatively small technology staff, so I work closely with the IT staff on many of the nuts-and-bolts details of our implementation.  I spent a lot of time tweaking the Apache config for this relaunch, and never ran into any "it can't do this" scenarios.  When I started at InfoWorld, we were running Netscape Enterprise Server 3.6 for Solaris (an utter nightmare in every way).  Mod_rewrite is reason enough to keep me happy for years.
  
• Migration to Resin as servlet engine.  We're only using it for our search at the moment, but expect more in the near future.  Stay tuned. 
  
• Squid reverse proxy for images.   I used to hear that you can have two of the following three things when buying a product -- cheap, easy, and good -- but never all three.  Squid disproves that axiom.
  
• Percussion Rhythmyx CMS:  I'll write more about this later in more detail, but suffice it to say that we really like this system (our sister company Network World uses it, too).  It's XSLT/Java-based with nice backend hooks, and the frontend provides MS Word integration, which makes it easy for our editors who already know Word.

Despite this redesign/CMS implementation being an "enterprise" project, I found once again that when the going gets tough, simplicity rules.  Scripting languages like Perl can get you out of a jam better than any off-the-shelf product or development environment.  It's a few years old now, but I haven't found a link checker I like more than Checklinks, a long -- but very fast -- Perl script that spits out easy-to-use reports of link problems on your site.

If you have any ideas or thoughts on the new site and the technology choices we made, let me know -- we're really excited about this design and look forward to building on it.  This is really only the beginning.

Web server performance testing

Preparing for the InfoWorld relaunch, we decided to do some benchmarking of Apache 2.0 versus Apache 1.3.26.  I made the assumption that Apache 2.0 would benchmark at least as well as 1.3.26 on our Linux boxes (running the 2.4 kernel).  It did for the most part, but its performance did not overwhelm 1.3.26 in any sense -- but benchmarks don't always (and usually don't) tell the whole story.

The ApacheBench program (found in the /bin directory of your Apache distribution) is my usual tool of choice.  As I ran it against Apache 1.3 and 2.0, Apache 2.0 would win handily at lower loads, then perform significantly less well at medium loads, then do much better than 1.3.26 at higher loads.  I sat on that for a second, then realized that ApacheBench issues HTTP 1.0 requests, which could be substantially more inefficient than our actual users' browsers, about 70% of which issue HTTP 1.1 requests based on a quick-and-dirty analysis of our logs)

gunzip -c access_log.20030123.gz | grep "HTTP/1.1" | wc -l

You can read about the differences between 1.0 and 1.1 here.  In any event, both Apache 1.3.26 and Apache 2.0 are indispensible for us here at InfoWorld.  Does anyone know of an ApacheBench-like benchmark tool that does HTTP/1.1?  Or am I too tired from all the redesign work to realize that all this doesn't really mean anything?