gzip vs no gzip

[mccajm]

What kind of infrastructure will check run on? If the server has a weak CPU, gzip should be disabled. If there's free capacity though, I'll send a pull request for the code.

Here's some initial stats for a linode 1024 at a concurrency of 400 (as required), without making any attempts to improve performance. The key thing here is the document length from the end-user point of view.

Testing was done over a 12MB/s link at a latency of 100ms.

Without gzip:(cpu: 350%, mem: 120MB on an 8 core VM)
Document Path: /
Document Length: 2739 bytes

Concurrency Level: 400
Time taken for tests: 6.633 seconds
Total transferred: 45664000 bytes
HTML transferred: 43824000 bytes
Requests per second: 2412.24 #/sec
Time per request: 165.821 ms
Transfer rate: 6723.18 [Kbytes/sec] received

With gzip: (cpu: 450%, mem: 100MB on an 8 core VM)
Document Path: /
Document Length: 1027 bytes

Concurrency Level: 400
Time taken for tests: 8.415 seconds
Total transferred: 19008000 bytes
HTML transferred: 16432000 bytes
Requests per second: 1901.29 #/sec
Time per request: 210.383 ms
Time per request: 0.526 [ms](mean, across all concurrent requests)
Transfer rate: 2205.80 [Kbytes/sec] received

[arlolra]

Those numbers look nice.

What kind of infrastructure will check run on? If the server has a weak CPU, gzip should be disabled. If there's free capacity though, I'll send a pull request for the code.

Andrew replied with some info here: https://trac.torproject.org/projects/tor/ticket/9529#comment:8

I get the feeling that they want apache to sit in front as an SSL terminator and then proxy requests to this service.

https://check2.torproject.org/ is already running this setup and seems to have gzip turned on for html content.

[arlolra]

Gzipping will most likely be handled by apache. There have been a number of changes to the codebase so these metrics are probably out of date. A great jumping off point though. See some performance improvements in #10 and #12.