4

My website forces HTTPS everywhere and has an average first load time of 3-5 seconds. Thanks to caching, repeat load time is 0.8 seconds.

The SSL negotiation takes 150-300ms on my server, so I want to keep each connection alive as frequently as possible to prevent latency.

SSLSessionCache is set to the default 300 seconds.

Apache KeepAlive Timeout was recently lowered from 5 seconds to 2 seconds.

This change has resulted in a noticeable decrease in Server Load Average (5% average instead of 10% average), but I'm wondering if it could also be causing slower first load times, if the first load times are 3-5 seconds? Does that mean it must perform the SSL negotation again each time it passes the 2 second timeout?

Is it better to have slightly higher load averages with fewer SSL negotations (but more sleeping httpd tasks), or lower load averages with more SSL negotations?

We definitely have plenty of CPU & memory resources to spare. So ultimately the question is, what will result in the best performance for our viewers? Raising the KeepAlive Timeout to 3-5, or keeping it at 2?

Thanks!

2
  • If the service is working well and the system is not overloaded - a high load average is a good sign IMO
    – aland
    Commented Oct 24, 2014 at 20:26
  • The server-status module has a nice overview of Session Cache status. If there is a high ratio of miss to hit, then either every session is new or your cache is too small. If people typically visit a site briefly and come back another day then the cache won't help much anyway, unless you turn the expiration way up, but that is a moving target.
    – Gerrit
    Commented May 1, 2018 at 15:22

1 Answer 1

0

Regarding server load: you don't say what operating system this is. For most flavours of Unix (including Linux) as long as the load is less than the number of CPUs then you probably shouldn't worry about it. In this scenario, each process gets to stay in the CPU for as long as it can do useful stuff there (more or less). But when there is a queue of proceses waiting to get to the CPU, the OS will interrupt tasks before they are ready to yield - when this happens your throughput starts to drop.

(I've never seen load expressed as a % before - where does this come from?)

Regarding page load times: Your server logs are not the place to look. If you want to find out if this is having an impact then you need to look at the page load waterfall in a browser (developer tools in Chrome, Firebug in Firefox or use an online checker such as pingdom - remember to use a proxy to add latency if you're testing locally). You are looking for gaps BETWEEN requests to your site greater than your keepAliveTimeout.

It is my experience that gaps of greater than 1 second are very rare, even on very slow networks. And where they do occur are either a result of an explicit delay (e.g. lazy-loading a new image in a slideshow) or (even rarer) a pathological fault in the page (e.g. retrieving a very large, blocking javascript from a very slow location).

(OK so we're actually looking for gaps between requests on the same socket - but this is difficult to visualize).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .