Excellent resource this site is. I’ve used it to really optimize page loading times but have come across an issue and am a little bit stumped.
Serving static content with nginx can be improved, but I don’t know where to start. Images are being served directly by nginx, yet I can’t get TTFB below ~120ms. The small delay seems to affect both dynamic (php-fpm) content or static content (pure nginx).
Hardware is top notch with 24 cores (E5-2620) with 64GB of DDR3 served from an Intel SSD – all brand new and in working order. mySQL databases are all in memory.
I’m convinced that the issue is with nginx or some OS-related issues nginx might be running into.
What I’ve tried with virtually no difference observed:
[list]
[]Disabling gzip compression
[]Changing gzip compression levels
[]Optimizing sysctl
[]Disabled logging, both error_log and access_log
[]worker_processes & worker_connections
[]Nginx microcaching
[*]keepalive_timeout / keepalive_requests
[/list]
I don’t believe there should really be much delay in serving content, especially when keepalive is on.
I am on nginx also but on the lower end and with slower ttfb, (220ms). You have to consider how you built nginx, what did you include in there as well as version numbers.
Also you have a lot to play with regarding worker processes and connections. Everyone seems to have a different formula. Since you got a lot of room to test things out I would build a script that would try out a few thousand variations of numbers of processes and connections , change the number, save, restart nginx, connect somewhere you can measure ttfb a dozen times, save times along with the settings, and restart. By the morning you might actually have some data.
When you dealing with tiny fractions of a second, you have to check your linux installation as well. Anything removable, don’t need? etc…
But the test script sounds like a winner to me. Especially since you can rerun the same numbers while changing another variable. I think its the easiest way to flush something out. Perhaps figuring out how close you can get to 0sec is a good idea too. Find some benchmarks, though I doubt they are out there, and too many braggarts to go by their word. lol
Remember that the overall TTFB as measured from WebPagetest also includes the round-trip time on the Internet from the test machine to your server (and for the connection profile - in the test case Cable adds 28ms).
The socket connect time is usually a good baseline to use for estimating the network-level RTT and it looks like in the test you are seeing ~110ms of network time just getting from WPT to your server.
Your actual server-side latencies for the static requests are closer to 15-40ms.
The only way to reduce the network latencies is to distribute your static content closer to the users which is exactly why CDN’s exist (real CDN’s, not cdn.lo4d.com which just appears to be a static file CNAME that is served from the same server or location).
[quote=“Sleepy_Old_Turtle, post:2, topic:8047”]
But the test script sounds like a winner to me. Especially since you can rerun the same numbers while changing another variable. [/quote]
Thanks for your suggest Turtle. I’ve been taking the approach, but I suppose more automation might be in order.
It’s pretty bare bones with the exception of apf, nginx, mysql, etc. I’m going to give it a look other though.
Good point about the real latencies. That’s exactly what I’m after improving and what I’d like to get down to. For image requests, I don’t really see the point of using a CDN provider unless it can really make a difference. I didn’t see any improvements in the past (hence the cdn.* addresses).
If you have visitors from around the world, a CDN can get rid of the network latencies from traversing the globe. That’s usually in the 100ms range from Europe to the US, 70ms between the US coasts and as much as 200-300ms between Asia and the US. That pretty much dwarfs your server-side latencies and it’s not something you will be able to test without actually distributing the content.
That said, it only really matters if you have visitors from further away. If all of your visitors are from within a few thousand miles of your server then it’s probably a wash.