On Tue, 25 Jun 2002, Schaedler, Joe wrote:
> The caching performance of your AWG is only tangentially related
> to your cell phone users web experience. If you are compressing
> the content, caching performance will help your AWG scale. This is
> due to the high latency of the wireless connection (provided you
> are talking cell phones and not 802.11). The tricky part is
> modelling a lot of lossy, high latency devices, for that I'm
> afraid your only choice is to use the "Dummynet" rate limiter on
> FreeBSD.
I agree that Dummynet is a good choice, and that is what Polygraph
workloads use for simulation of packet-level properties like packet
loss and delay.
Also, I have seen a recent research paper using Polygraph for testing
content-compression-dependent optimizations. It looks like it was
fairly easy to get a realistic workload with compression. I do not
know whether AWG is sending compressed content to the client and/or
receiving compressed content from the server, but if it does, I would
be interested in developing a Polygraph workload that exercises those
important features correctly.
> We had a vendor use it for a capacity test and found that they
> could reach about 2000 connections per rate limiter without a
> major degradation in bandwidth. Even then that required almost 20
> FreeBSD boxes. Hardware-based rate shapers are a better way to go
> but can be expensive.
While I do not know the details of your setup, I am surprised it took
~~20 FreeBSD boxes to get 2000 connections. With a recent and tuned
FreeBSD kernel and correctly configured Web Polygraph, I would expect
to be able to get the same performance with a single client-server
pair, maybe two. Perhaps your environment was very different from what
I am imagining... If you ever need to run a similar test, let's talk
how you can try to avoid using so many PCs!
Thanks,
Alex.
This archive was generated by hypermail 2b29 : Mon Feb 06 2006 - 12:00:23 MST