John Buckman pointed out in this thread that AOLserver wasn’t working right on his 64-bit Linux box that he wants to upgrade BookMooch to. I offered to help, but pointed out that I don’t have a machine to test on–so, he graciously provided me temporary access to one of his machines to diagnose the problem.
After some poking and prodding, I believe the correct change to get AOLserver to build is to edit include/ns.mak on line 79, after running configure which generates it from ns.mak.in. Change the line from:
LDLIB = ${CC} -shared ${CFLAGS} ${LDFLAGS}
to:
LDLIB = ${CC} -nostartfiles -shared ${CFLAGS} ${LDFLAGS}
Simply add the “-nostartfiles” after “${CC}” in the LDLIB variable. I reported this to the AOLserver mailing list as well.
John confirms that he’s now able to run AOLserver on his luscious new 64-bit 2-CPU Xeon E5335 Clovertown quad-core box.
In return, I asked John to do me a favor and perform a simple benchmark, fetching a 4K static file from AOLserver using ApacheBench, and here’s what you might be able to expect:
# ab -c 50 -n 50000 http://.../x.txt ... Server Software: AOLserver/4.5.0 Server Hostname: ... Server Port: 80 Document Path: /x.txt Document Length: 4070 bytes Concurrency Level: 50 Time taken for tests: 3.281485 seconds Complete requests: 50000 Failed requests: 0 Write errors: 0 Total transferred: 217654353 bytes HTML transferred: 203504070 bytes Requests per second: 15237.00 [#/sec] (mean) Time per request: 3.281 [ms] (mean) Time per request: 0.066 [ms] (mean, across all concurrent requests) Transfer rate: 64773.42 [Kbytes/sec] received
No, that’s not a typo: 15,237 requests per second. This is without any tuning or tweaking of the IP stack or anything. Of course, 15K req/sec at 4K per request is ~218MB–over a span of 3.2 seconds is effectively 544 Mbps, so you’re more likely to run out of upstream network bandwidth than run out of horsepower serving static assets out of AOLserver on this kind of hardware.
Naturally, you shouldn’t epxect this kind of throughput on dynamic requests and benchmarking those isn’t really meaningful since the nature of your application code will greatly affect the request execution time. However, it’d be fun to do a “web server shootout” where each implements a trivial piece of dynamic functionality in their best environment–Apache with mod_perl, mod_python, FastCGI/PHP, etc. vs. AOLserver with Tcl–and see which one has the least amount of overhead.
Still, it’s great news that John’s BookMooch service is going to be able to move to a beefy 64-bit box, and I’m very glad to know that 64-bit AOLserver does run just fine for at least one application on Debian Linux.
Tags: AOLserver, 64-bit, Linux, John Buckman, BookMooch








March 12th, 2010 at 10:30 pm
Mikki: I would hazard a guess that any reasonably experienced technician should do an adequate job. Obviously, every individual ...
March 12th, 2010 at 9:52 pm
Okay...now you have me worried...I've had my WONDERFUL Bosch washer/condensation dryer for about 8 years without a problem (okay so ...
March 11th, 2010 at 8:45 am
I'm not sure, but I'm guessing it's the belt that turns the drum - may be too tight, may be ...
March 11th, 2010 at 6:57 am
Hello all. I now have a different problem. The drum groans as it spins. When you try ...
March 10th, 2010 at 9:35 pm
Hi Dossy, Thanks much for sharing the knowledge with others. This article helps me to avoid DISM errors : ...