There are many issues that become more difficult to resolve in a single tasking web server than in the normal forking model. Here is a partial list -- there are probably many that haven't encountered yet.
Performance is a very difficult thing to quantitatively measure. Due to the fact that there are very few good and accessible performance benchmarks, our benchmarking is limited to very simple means. We use the Benchmark ZeusBench, which may no longer be available. ZeusBench takes only a few commandline parameters, which makes it easy to use. It is also useful as a diagnostic tool.
ZeusBench has the capacity to make its requests over Ethernet as well as localhost. However, as bad as using localhost for anything might well be, it *does* eliminate to a great deal the bottleneck that is Ethernet. As a standard rule, we use options that have ZeusBench attempt to make either 10,000 or 20,000 successful requests.
The following benchmarks were run on a GNU/Linux 2.0.33 egcs 1.0.1 compiled kernel, on an Intel Pentium 200 MMX, over localhost, and with a file size of 2448 bytes. Each server was tuned with the following options: access logging turned off, 100 keepalive, and no DNS lookups or unnecessary modules for Apache.
Like so many benchmarks, these are to be taken with a grain of salt.
--- Server: Boa/0.93.9 Doucment Length: 2448 Concurency Level: 215 Time taken for tests: 27.526 seconds Complete requests: 20000 Failed requests: 0 Keep-Alive requests: 20091 Bytes transfered: 53743425 HTML transfered: 49182768 Requests per seconds: 726.59 Transfer rate: 1952.46 kb/s Connnection Times (ms) min avg max Connect: 0 2 325 Total: 87 292 5602 ---
--- Server: Apache/1.2.5 Doucment Length: 2448 Concurency Level: 215 Time taken for tests: 38.100 seconds Complete requests: 20000 Failed requests: 0 Keep-Alive requests: 19850 Bytes transfered: 54576586 HTML transfered: 49035804 Requests per seconds: 524.93 Transfer rate: 1432.46 kb/s Connnection Times (ms) min avg max Connect: 0 0 101 Total: 4 250 37783 ---
As can be seen, Boa is significantly faster than Apache.
The file systems being served should be much faster than the network connection to the HTTP requests, or performance will suffer. For instance, if a document is served from a CD-ROM, the whole server (including all other currently incomplete data transfers) will stall while the CD-ROM spins up. This is a consequence of the fact that Boa mmap()'s each file being served, and lets the kernel read and cache pages as best it knows how. When the files come from a local disk (the faster the better), this is no problem, and in fact delivers nearly ideal performance under heavy load. Avoid serving documents from NFS and CD-ROM unless you have even slower inbound net connections (e.g., POTS SLIP).
Writing a nonblocking gethostbyaddr is a difficult and not very enjoyable task. Paul Phillips experimented with several methods, including a separate logging process, before removing hostname lookups entirely. There is a companion program with Boa util/resolver.pl that will postprocess the logfiles and replace IP addresses with hostnames, which is much faster no matter what sort of server you run.
Same difficulties as hostname lookups; not included. Boa provides a REMOTE_PORT environment variable, in addition to REMOTE_ADDR, so that a CGI program can do its own ident.
If users are allowed to serve HTML from their home directories, password file lookups can potentially block the process. To lessen the impact, each user's home directory is cached by Boa so it need only be looked up once.
Since a file descriptor is needed for every ongoing connection
(two for non-nph CGIs, directories, and automatic gunzipping of files),
it is possible though highly improbable to run out of file
descriptors. The symptoms of this conditions may vary with
your particular unix variant, but you will probably see log
entries giving an error message for
Try to build your kernel to give an adequate number for
your usage - GNU/Linux provides 256 out of the box, more than
enough for most people.
In the pursuit of speed and simplicity, some aspects of Boa differ from the popular web servers. In no particular order:
The REMOTE_HOST environment variable is not set for CGI programs, for reasons already described. This is easily worked around because the IP address is provided in the REMOTE_ADDR variable, so (if the CGI program actually cares) gethostbyaddr or a variant can be used.
We don't like them, and they are too slow to parse. We will consider more efficient alternatives, see the todo.txt to-do list.
Boa will follow symbolic links, and serve any file that it can read. The expectation is that you will configure Boa to run as user "nobody", and only files configured world readable will come out. See the todo.txt to-do list.
There is no option to run chrooted. If anybody wants this, and is willing to try out experimental code, contact the maintainers.
Like any good server, Boa traps SIGHUP and rereads boa.conf. However, under normal circumstances, it has already given away permissions, so many items listed in boa.conf can not take effect. No attempt is made to change uid, gid, log files, or server port. All other configuration changes should take place smoothly.
Not all browsers handle relative URLs correctly. Boa will not cover up for this browser bug, and will typically report 404 Not Found for URL's containing odd combinations of "../"'s.