Performance Tuning for MacHTTP

There are lots of different ways to get MacHTTP to "go real fast." This document discusses a few of the factors that affect MacHTTP's performance and how you can adjust them.

Network Performance

The biggest factor affecting MacHTTP's performance is related to network speed. At first glance, it would seem that the faster your network, the faster MacHTTP can run. This is obviously true if all the clients are on the same 10 megabit ethernet with your server. However, this isn't the real world for most public MacHTTP servers. You'll have a mix of clients from high-speed nets all the way down to slow SLIP and PPP users.

Mixing network speeds like this means MacHTTP needs to be tuned to accomodate the variety of networks it will be transmitting to. If MacHTTP is sending data to a client on a PPP connection, connected at 14.4 kbps, this means that it's going to take about 1 second to send 1k of data. DUMP_BUF_SIZE is the configuration parameter that you can adjust to accomodate slower connections. The smaller the DUMP_BUF_SIZE, the faster MacHTTP can shove a buffer of data out to slow client without slowing down all the other connections.

Unfortunately, there is a point of diminishing return, where the smaller DUMP_BUF_SIZE begins to cause MacHTTP to spend more time thrashing through servicing connections than sending data. Usually a value between 512 and 2048 works well for slow clients. If you have a lot of high speed clients, MacHTTP performs better with larger DUMP_BUF_SIZE settings like 4096 or 8192. Experimentation is the order of the day to determine the optimum size.

Cooperating with other Mac Applications

If you plan on running MacHTTP in the background while you use your Mac for other things, you might want adjust it to be a little more friendly. When MacHTTP gets busy, it will hog the processor as much as you allow it. The PIG_DELAY setting is used to adjust how much processor time MacHTTP uses before allowing other applications to run. The bigger the number, the more time it uses. The smaller the number, the less impact MacHTTP has on other applications.

PIG_DELAY is measured in 60ths of a second. An average setting is 30, or 1/2 of a second. When the server is really busy, MacHTTP runs non-stop for this long before allowing other Mac applications to run. This can cause your applications to appear jerky. Decreasing this number to something like 15 or 20 allows other applications more time to run. Decreasing PIG_DELAY too much will cause MacHTTP to be unable to service its connections at a reasonable level of performance. Experiment!

Running Multiple Servers

Another way to speed up MacHTTP is to run multiple MacHTTP servers, on multiple Macs. It's always the case that 10 SE/30s will always outperform a single SparcStation, for example. Multiple, inexpensive Macs can have WWW documents spread across them, with URLs on the various Macs referring to each other.

A more complicated technique is to set up duplicate document trees on multiple Macs, and rely on the domain name service to randomly connect clients to one of these identical servers. You must configure the same domain name for each of these Macs, which have different IP addresses. Newer versions of DNS servers will be able to randomly return different IP addresses for each client requesting the same name.

User Load

It's very easy to have your server get swamped with connections, especially if you have a slow network connection. Requests can come in faster than you can transmit data to the clients. MacHTTP allows you to adjust the number of simultaneous connections using the MAX_USERS config variable. If you aren't running a Power Mac, MacHTTP will start to get bogged down when more than 15 or 20 connections are active. MacHTTP deals with this overload by gently turning away clients when it is too busy. It uses a reply message that many clients understand to mean "try again in a few seconds", so some users won't even notice a problem.

The basic rule of thumb is to watch the MacHTTP status window (the bar graphs) and adjust the MAX_USERS variable up or down, based on your server's load and performance under that load. Don't be afraid to restrict the number of connections if your server cannot handle the load.