ndn12logic: everything (scoped)
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

1. Test summary table

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.2
reporter version:
4.3.2

2. Test summary phases

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.


3. Hit Ratios

Hit Ratios DHR
(%)
BHR
(%)
measured 79.65 79.02

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.




4. Cheap proxy validation

Cheap proxy validation DHR
(%)
BHR
(%)
measured 79.65 79.02

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




5. Byte Latency

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
Client Byte Latency Histogram
latency.histogram.client_figure.scope=sides=client,server__phases=meas
Server Byte Latency Histogram
latency.histogram.server_figure.scope=sides=client,server__phases=meas

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.