From: Stephen D. Williams (sdw@lig.net)
Date: Thu Jun 08 2000 - 21:19:18 PDT
"Adam L. Beberg" wrote:
> On Tue, 2 May 2000, Kragen Sitaker wrote:
>
> > Adam Beberg writes:
> > > On Tue, 2 May 2000, Rohit Khare wrote:
> > > > Here's where it gets a bit technical. WebScaler takes care of the
> > > > normally processor-intensive tasks involved in setting up and
> > > > processing users' Transport Control Protocol requests, off-loading
> > > > those duties from the site's Web servers.
> > >
> > > My god! It's a front end web proxy! How long has everyone running
> > > mod_perl or any SQL engine been using this as a standard bit-pushing
> > > technique now?
> >
> > It's not a front-end web proxy, actually. It doesn't cache any
> > content. It just turns all requests over new connections into requests
> > over existing TCP connections.
>
> Exactly the method that I spoke of. Two running versions of Apache, one
> with mod_perl or SQL, and another that's a non-caching proxy. The first
> can saturate with "heavy" requests and burst the data to the second
> copy, immediately moving on to another heavy request. The second handles
> slowly sending data to all those modems out there. If you tweak this
> slightly with some caching, it's functionally exactly what's described
> in the release, one server connect to many clients. If the release is
> misleading, that's not my problem ;)
It sounds like they have a hacked TCP stack and map layer 3 (TCP data)
requests semantically to existing TCP connections via Http 1.1 pipelining. In
fact, I was planning to implement just such a hacked TCP stack but for
additional reasons beyond increasing HTTP traffic capability. Modifying
Apache was something I've considered.
What you are talking about is something like Squid in reverse-proxy/cache
mode. What they have is a step beyond that, but semantically equivalent. In
actuality they have optimized TCP/IP processing which means A) custom OS, B)
hacked OS, or C) custom packet processing with efficient pipelining.
> Now, 320,000 TCP/sec is damn impressive, since even with the smallest
> TCP packets possible (one byte requests) that's well more then a 100Mbit
> connection to the net will handle. With realistic sized packets they are
> claiming gigabit bandwidth. Screw the proxy, I want one of whatever
> hardware they run on (and the 22 T3's so i can use it).
Indeed. At 41 bytes/packet (minimum for IPv4 with 1 byte of data) and if Fast
Ethernet is 100 true MegaBits, rather than decimal hard-drive 'mega', and if
framing is is ignored or already taken into account by the stated '100 Mb',
then you can send 319687 minimum-sized packets per second. It seems likely
that they based their spec on this number even though starting a TCP
connection requires two packets in, one out and closing a connection requires
two in and two out, not including any data you want to send. The likely
number for raw connections sans data is therefore 319687/5 = 63937. Sending
any data, including slow start acks, will severely curtail this number.
Even at 30,000 connections/second: this is 2.6 Billion connections per day,
off most charts.
For comparison, a medium-fast PC server (Celeron 500) with Apache 1.3.9 (last
I tested) and a contemporaneous Squid serving the same small (8k I think, may
have been smaller) documents repeatedly produced the following results:
Apache only, 120 documents/tcp connections per second. (I found published
results of up to 150/sec.)
Squid in reverse-proxy in front of Apache, 500 documents/tcp connections per
second.
This was tested with one client progam over Fast Ethernet with a low-end
managed switch.
Of course SGI and IBM have both released enhancements to Apache since then.
Note that the description compares their device to a 'surge protector'. It's
quite possible that it can only burst to this kind of speed and not maintain
it for any length of time, even on the order of seconds. The latency
requirements of typical connections coupled with buffer requirements are a big
problem.
Still I like seeing this area fleshed out more. It is needed, at least until
some serious optimization is performed at the OS and kernel level.
> - Adam L. Beberg
> Mithral Communications & Design, Inc.
> The Cosm Project - http://cosm.mithral.com/
> beberg@mithral.com - http://www.iit.edu/~beberg/
sdw
-- Insta.com - Revolutionary E-Business Communication sdw@insta.com Stephen D. Williams Senior Consultant/Architect http://sdw.st 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax Jan2000
This archive was generated by hypermail 2b29 : Thu Jun 08 2000 - 21:23:47 PDT