httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob McCool <>
Subject Re: HTTP/1.1 implementation speeds (was Re: votes for 0.6.3)
Date Fri, 05 May 1995 06:55:21 GMT
 * "Re: HTTP/1.1 implementation speeds (was Re: votes for 0.6.3)" 
 *    written Thu, 4 May 1995 20:33:44 -0700 (PDT)
 * It's very easy to
 * get bogus numbers on benchmarks, because there's no agreed on
 * standard. The CommerceNet WebStones RFP should be out soon, and
 * that looks like it should end up with something pretty sane-
 * however doing benchmarks right gets pretty hard. A lot depends on
 * the speed of the client's network connection; loads that are fine
 * if everyone is on a T1 can knock a server completely out of shape
 * if you change to V32bis modems. It's kind of hard to distill this
 * sort of performance curve into a single '10x' ratio.

[okay, my turn then]

And I agree. We found that problems that never showed up in the lab
(simulated load) suddenly created very real problems for Nearly all of them turned out to be things that
needed to be fixed at the TCP level; most of them weren't at the
application level. The benchmarks I've seen thus far can't effectively
capture the parallelism and bursts inherent in real-world TCP loads.

Contrary to what people might think, Netsite was not designed to be
the fastest HTTP server ever. It was designed with more modest goals
in mind: build a high performance HTTP server that's good enough for
the loads seen by real sites both today and in the near
future. Functionality has always taken precedence over performance. We
could have done some things to make it faster; servers which use
kernel threading where available or some type of non-preemptive user
level threads will probably win over multiprocess models.

But we had reasons unrelated to performance to avoid a single process
design. Lack of portability, the possibility for catastrophic
instability, and an abnormally short development cycle were very real
concerns for us. I actually wrote several papers on the design of
Netsite a while back, I don't know if they'll ever be published
outside the company.

And how many customers are going to benefit from that kind of a
difference? Less than 1%? Less than 5%? Netsite is thread ready, runs
threaded under NT with very little additional code, and when
persistent connections are added (probably for the next release if
standards go well) we'll undoubtedly start using them under UNIX.

But at this point, the interesting performance work is not going to
take place at the application level, it's going to take place at the
protocol level. We've routinely done over three million hits a day on
one machine with our software, and that's more traffic than just about
anybody on the Web today is going to get in the near future.


View raw message