The purpose of the benchmark was to examine the effect of several parameters on end-to-end latency in the optimistic delta system: delta size, server latency, and cache contents. We considered delta size by retrieving many pages with different characteristics. We examined the effect of server latency by varying the response time prior to sending data to the server proxy (see below). Finally, we evaluated the difference between sending deltas to a client with the past version of the page cached and one without it cached. (In the case of the unmodified proxy, without deltas, caching was irrelevant because each version of the page was retrieved exactly once.) All requests were made with Pragma: no-cache, and the pages always differed upon each retrieval. Other cases, such as when the page has not changed or the server proxy can return its cached copy, are relatively uninteresting: they either favor the optimistic approach or are equivalent between the two systems.
In each run of the benchmark, the client system retrieved each URL repeatedly, once for each version that existed. A CGI script mapped the URL into a local filename that is dependent on the next version for that URL: the first GET on /deltatest/pageN returned /deltatest/pageN/1, the second returned /2, and so on. Thus to the ``browser'' (actually the benchmark program) and the proxies, the same URL mapped to new versions of the page upon each request.
In addition, the CGI script read a file to determine how much of a delay
it should insert before responding, which was used to simulate delay
in the Internet and/or on the content provider.
Longer delays permit
more of an opportunity for optimistic transfers of large documents but
also place a larger lower bound on end-to-end latency: if a server takes a
minute to respond, then it will be at least a minute before the client
proxy knows it has the current version of the page.
We therefore expected that the runs with no added latency would
show a high benefit from cached deltas and suffer delays from
ill-placed optimistic transfers of the old copy that could not fit
into the 
idle period, while runs with significant added
latency would favor the optimistic approach but gain less from sending
cached deltas (the amount of time saved as a fraction of total latency
would decrease due to the fixed overhead).
For the current set of experiments, we were forced to restrict the range of parameters to keep the experiments tractable in a limited time frame. We did this in two respects: