* 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
