For the longest time, the only Web server software that really amounted to anything was either Apache (for the Unices) or IIS (for Microsoft Windows). These two continue to dominate the market and, more than likely, will for years to come. But there are other players out there, even other cross-platform players.

One is the relatively new Xitami Web server, billed as a small, fast, and powerful multiplatform open source Web server. The product comes in two forms: the free version and Xitami Pro. The only difference between the two (other than the price) is that Pro adds an SSL layer, which supports SSL/2, SSL/3, and TLS strong encryption.

In this Daily Drill Down, I’m going to deal with the installation on both the Windows platform and the Linux platform. I’ll limit the demonstration to the free version of the software. I’ll also run some benchmarking to see how the server compares to the industry leaders.

Installation – Windows
I installed Xitami on a single processor Windows 2000 machine. For the purpose of this test, I selected the Turbo installation to get the fastest possible performance. The installation is actually, in true Microsoft form, quite simple: Download the executable file, double-click the icon when the download is complete, and answer a few questions.

After the installation was complete, I had to create two simple files: defaults.cfg and defaults.aut. The defaults.cfg file simply determined where the system could find the file that contained the usernames and passwords, and the defaults.aut contained the actual usernames and passwords. The defaults.cfg looks like this:
[Security]
        filename=defaults.aut

The defaults.aut file looks like this:
[/Admin]
    admin=verysecret

As you can see, the first file, defaults.cfg, directs the call to the defaults.aut file to validate the username and password (in this case the username will be admin and the password will be verysecret). The files will be placed in the C:\Xitami directory. There’s no need to restart the server because it will reread that directory after 60 seconds. This configuration is primarily for the Web-based administration tool.

Once that’s done, Xitami is set to rock. You’ll notice a small, green circle with an X through it in your system tray. From there, you can start, stop, and configure Xitami.

Installation – Linux
The Linux installation was almost as simple: Download the gzipp’d tar file, put it in /var/www/html/, and then run the following commands (as root):
tar xvzf suni24d9.tgz
cd xitami-24d9
./xiconfig

which then asked me for an administrator name and password. Once that was entered, it asked whether I wanted to allow remote access to the Web-Based Administration (WBA). I chose yes (y); I knew that I would want to get my hands on the WBA tool. This step completed the configuration stage of the build.

The next step was to run:
./xibuild

which built the application and, finally, told me that I could test the application by running the command xitami and pointing the browser to http://hostname or http://hostname:5080.

Of course, if /var/www/html/ isn’t in root’s $PATH, simply running xitami won’t work. Instead, I’d have to run the command in one of two ways: either from the directory I compiled Xitami in with the command ./xitami or with the complete path /var/www/html/xitami-24d9/xitami.

Once it’s up and running, I can always put the full command (including path) into /etc/rc.d/rc.local to have it start up at boot.

Benchmarks
Are you sitting down? If not, please do. All three servers were set up on the same machine from PogoLinux, an Athlon 750 with 256 MB of RAM. One at a time, I started, tested, and shut down each server. I used the httperf benchmarking software, and the command for the single test looked like this, which makes httperf generate a total of 10 sessions at a rate of one session per second (each session consisting of five calls spaced two seconds apart).

For a harsher test, I used this command, which makes httperf generate a total of 1,000 sessions at a rate of one session per second (each session consisting of 100 calls spaced one second apart).

The results of the first test are shown in Figure A.

Figure A

The results of the first test are fairly telling. You can see that Apache kicked back very similar results on both Windows and Linux, with the Linux version marginally beating the Windows version in nearly all categories. IIS fared surprisingly well, coming quite close to the Linux Apache server. Xitami is another story: The Xitami server decimated its competition.

For example, look at the Request Rate data. From Windows Apache, we see 46.6 requests per second at 21.4 milliseconds per request. From Linux Apache, we see a marked improvement of 91.1 requests per second at 11.0 milliseconds per request. IIS responds only a tenth of a request per second behind Linux Apache, with 91.0 requests per second at 11.0 milliseconds per request.

Jump over to Xitami and the improvement is exponential. Under Windows, Xitami handled 180.7 requests per second at 5.5 milliseconds per request.

Finally, Linux Xitami took up 181.1 requests per second at 5.5 milliseconds per request. The jump from the slowest (Apache running under Windows) to the fastest (Xitami running under Linux) is a 74.3 percent improvement. But does it scale? To test this question, I decided to hit all the servers with a much larger number of requests from multiple machines at one time.

To pull off this test, I hit each server with two machines, ran a much more demanding command, and recorded those results. For simplicity’s sake, I only retained one machine’s results (using the same machine throughout), which I’ve listed in Figure B.

Figure B

This test was a bigger hit on all of the servers, regardless of platform. What’s interesting is that the results aren’t exactly parallel to the first test. Even though the hardware and the installations didn’t change, adding the larger load and the second client drastically changed the results. IIS was the only server whose results had minimal changes. Although it still didn’t come close to Xitami, IIS held steady.

Does the outcome of this test bode poorly for Xitami? As I scaled the test, I saw a decline in the improvement. To test this theory, I bumped the command up another notch and ran it on both IIS and the Linux Xitami server and came back with the results shown in Figure C.

Figure C

As you can see from the results of the third test, the Xitami server continued to blow away the IIS server in most areas. Look at the CPU time, though. The results show the exact same results for both servers. This was after switching Xitami from Turbo configuration to Normal. Before making the switch, Xitami was using 100 percent of the CPU; IIS only soaked up 50 percent. Why is this? After I looked into the configuration of Xitami, it became clear that the difference was in the performance configuration. Both IIS and Apache run as background (daemon) servers. The Xitami server, when set at Turbo, runs as an application and quickly consumes CPU cycles because it’s continually running in the foreground.

Although great for performance, this serves your hardware none too well. If you have any interest in preserving those precious servers, you’ll want to visit the Xitami setup page, either by clicking the Web-Based Admin link on your server’s main Xitami page or entering http://server.ip.addy/admin.

server.ip.addy

Where you see server.ip.addy above, you’ll enter the actual IP address of your server.

From the Web-Based Admin screen, click the Configuration button and, within the new window, click Advanced. On the Advanced Configuration screen, you’ll see the Server Performance configuration entry. Select Background, click the Save button, and click the Restart button. Your server will now be running as a daemon server, which will make a hit on your performance but should save a good deal of CPU cycles.

Conclusion
The Web server space is a vast vacuum where the astronauts cling to statistics like oxygen. You can believe the cynics, the naysayers, and the pundits, but take it from the poster child for Linux evangelism: Xitami is worth looking into. I’ve tested it, and it passed with flying colors. Its speed, size, simple administration, and price all make it a very worthy contender for your Web site needs.