client side | baseline | all phases | meas |
---|---|---|---|
server side | baseline | all phases | meas |
all sides | baseline | all phases | meas |
highlighted cell(s) above show current scope |
---|
links point to other scopes |
label: ndn12logic throughput: 3.88xact/sec or 0.34Mbits/sec response time: 799msec mean hit ratios: 79.65% DHR and 79.02% BHR unique URLs: 1520xact (79.92% recurrence) errors: 1.32% (100xact out of 7568xact) duration: 32.48min start time: Thu, 08 Dec 2011 19:50:01 GMT workload: available Polygraph version: 4.3.2reporter version: 4.3.2
This executive summary and baseline report statistics are based on the following 1 test phase(s): meas. The test has the following 1 phase(s): meas.
The hit ratios table shows measured hit ratios. Hits are calculated based on client- and server-side traffic comparison. Offered hits are counted for 'basic' transactions only (simple HTTP GET requests with '200 OK' responses). Measured hit stats are based on all transactions. Thus, 'offered' hit ratio are not the same as 'ideal' hit ratio in this context.
Measured hit count or volume is the difference between client- and server-side traffic counts or volumes. DHR, Document Hit Ratio, is the ratio of the total number of hits to the number of all transactions. BHR, Byte Hit Ratio, is the ratio of the total volume (a sum of response sizes) of hits to the total volume of all transactions. Negative measured hit ratios are possible if server-side traffic of a cache exceeds client-side traffic (e.g., due to optimistic prefetching or extra freshness checks) and if side measurements are out-of-sync. Negative measured BHR can also be due to aborted-by-robots transactions.
A less accurate way to measure hit ratio is to detect hits on the client-side using custom HTTP headers. A hit ratio table based on client-side tricks is available elsewhere.
The 'Cheap proxy validation' table is similar to 'Hit Ratios' table. But it reflects hit ratios that would have been observed if successful (i.e., useless or in vein) validation initiated by the proxy were so 'cheap' that they could have been ignored rather than decrease measured hit ratio. The following formula is used to calculate cheap proxy validation hit ratio:
cheap_proxy_validation_hits = all_client_side_responses - all_server_side_responses + useless_server_side_proxy_validation_responses
cheap_proxy_validation_HR = cheap_proxy_validation_hits / all_client_side_responses
Byte Latency Written (msec) Read (msec) Min Mean Max Min Mean Max Last request byte 0.00 25.85 8997.00 0.00 0.00 3.00 First response byte 0.00 0.00 4.00 44.00 639.42 9106.00
The 'first response byte' latency is the time it took Polygraph to read (or write) the first response byte. The timer starts when the transaction starts. The timer stops when the server writes the first response byte to the TCP socket or the client reads the first response byte from the socket.
Similarly, the 'last request byte' latency is the time it took Polygraph to read (or write) the last request byte. The timer starts when the transaction starts. The timer stop when the client writes the last request byte or the server reads the last request byte.
Usually, more than one byte is read or written in one I/O operation, but a single-byte I/O is sufficient to stop these latency timers. Only HTTP-level bytes can stop the timers. Low-level content exchanged during TCP or SSL handshakes and negotiations has no effect. These stats are collected for basic transactions only.