Last year I created (with invaluable assistance from other project team
members) a fairly detailed discrete-event simulation of proxy caching
systems and their interactions with clients and origin servers, using
the CSIM18 library on Linux. The purpose was to study the effects of
various caching algorithms and configuration options.
The client and origin server behavior is closely modeled on that of Web
Polygraph (as of the third cache-off), and most of the Polygraph options
are supported, in particular the workload characterization options.
Network behavior is simulated down to the packet level, including
connection establishment, TCP slow-start, and HTTP persistent
connections. (This all turns out to be very important.)
Performance characteristics of the proxy cache hardware can be
determined
from published specifications: number of CPUs; clock rate; memory size;
disk seek and latency times, data transfer rates, buffer sizes; NIC data
transfer rates. One thing that cannot be determined from specs is the
CPU resource requirements for the various operations in the proxy cache
software (receiving requests from and sending replies to clients,
checking cache metadata, retrieving objects from the cache, sending
requests to and receiving replies from origin servers, etc.). The CPU
requirements obvious vary depending on the operations required to
satisfy a given request. To measure this, we set up a testbed with a
real caching proxy and Polygraph clients and servers, and ran several
extremely artificial loads (all memory hits, all misses, all reval
successes or failures, etc.) in order to dis-entangle the threads.
Although the project was canceled before these measurements could be
completed, we did obtain some very interesting (and surprising)
preliminary results.
There are actually several different algorithms that specify the
operation of a proxy: cacheability, RAM cache promotion, disk
allocation, revalidation, replacement, and multi-proxy load sharing.
Several varieties of each these were implemented.
Several kinds of results can be reported, such hit rates and response
times (broken down by Squid types) and resource utilizations (CPU, disk,
network).
All of the above properties of the simulation can be dynamically
configured. The simulation is configured for a given run via a
parameters file, so that a non-programmer can try out different
algorithms and configurations.
The speed of the simulation obviously depends upon the request rate and
the nature of the traffic, but simulated time ran an order of magnitude
faster than actual clock time at a rate of several hundred requests per
second on an old 400 MHz Pentium II.
It was originally intended to make this into a commercial-grade tool,
but the project lost its customer and was canceled before this
was completed. My former employer owns the rights to this code,
but it could probably be licensed, and it's possible that they would
grant a rolalty-free license for research use. The simulation could
also be re-created from scratch. Although it's not easy, proxy caching
systems can be simulated at a level of detail that provides useful
results.
This archive was generated by hypermail 2b29 : Mon Feb 06 2006 - 12:00:20 MST