* Kevin Fenzi:
So, we have been talking about how to distribute things more, and we
could also consider just moving it to a more central location.
It would be nice to have a URL with truly static content, to mostly
rule out application server load issues.
For a worst-case connection without any caching (besides DNS), I get
this:
$ time wget -S -O/dev/null
https://pagure.io/does-not-exist
--2017-03-25 20:43:18--
https://pagure.io/does-not-exist
Resolving pagure.io (pagure.io)... 140.211.169.204,
2605:bc80:3010:600:dead:beef:cafe:fed8
Connecting to pagure.io (pagure.io)|140.211.169.204|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 404 NOT FOUND
Date: Sat, 25 Mar 2017 19:43:18 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.1e-fips mod_wsgi/3.4
Python/2.7.5
Set-Cookie: pagure=eyJfcGVybWFuZW50Ijp0cnVlfQ.C7hZ1g.XYNmfFpfoHoxQatH3iWmXQPLJZg;
Expires=Tue, 25-Apr-2017 19:43:18 GMT; Secure; HttpOnly; Path=/
Strict-Transport-Security: max-age=15768000; includeSubDomains; preload
Content-Length: 2994
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
2017-03-25 20:43:19 ERROR 404: NOT FOUND.
real 0m0.839s
user 0m0.016s
sys 0m0.000s
The RTT to the server is around 182ms. I think this already includes
some delay from the application itself, beyond what is necessary by
TCP and HTTPS.
The latency seen by the browser will be somewhat lower than this (even
if HTTPS session resumption cannot be used). Not sure if there is a
ready-made tool to measure that.
If the application is somehow to blame for delays, distribution across
multiple data centres is likely to make it much worse because
increased RTT to the database.