Délka trvání zátì¾ového testu byla osm hodin a v jeho prùbìhu jsme chtìli nasimulovat dva dny na¹í virtuální firmy, která pou¾ívá na¹í proxy cache. Popis zátì¾ového scénáøe vypadá takto:
| Jméno fáze | Zátì¾ na zaèátku [req/s] | Zátì¾ na konci [req/s] | Doba trvání [min] |
| Morning | 7 | 35 | 24 |
| Day | 35 | 35 | 177 |
| Evening | 35 | 7 | 24 |
| Night | 3.5 | 3.5 | 48 |
| Morning | 7 | 35 | 24 |
| Day | 35 | 35 | 177 |
| Evening | 35 | 7 | 48 |
Velièina req/s udává poèet po¾adavkù za vteøinu, kterou generovali WebPolygraph klienti na proxy server. Ve fázích Morning resp. Evening se tato rychlost postupnì zvy¹ovala resp. sni¾ovala. Na¹e proxy cache tedy musela èelit zátì¾i, kterou udává tabulka. Prùmìrná velikost objektu, kterou generovali WebPolygraph servery byla nastavena na 3kb. WebPolygraph servery byly té¾ nastaveny tak, aby 80% objektù bylo cachovatelných. Tyto objekty nemìly ve své HTTP hlavièce uveden ¾ádný øádek, který by proxy cache zakazoval ulo¾it daný objekt na disk (napø. Pragma: no-cache). Dále jsme nastavili, ¾e na 55% v¹ech dokumentù se WebPolygraph klienti budou ptát znova. To znamená, ¾e pokud proxy cache objekty správnì cachuje, zaznamená na tìchto 55% dokumentù WebPolygraph klient tzv. cache hit (dokument je stáhnut z proxy cache a ne z cílového WebPolygraph serveru).