If you use multiple Listen statements to listen on either multiple ports or multiple addresses, Apache needs to use select() in order to test each socket to see if a connection is ready.
If you only use a single Listen statement, Apache uses accept() instead of select(). All children can just block in accept() until a connection arrives.
There’s a long discussion about the inefficiencies and syncronization difficulties of using a select() loop rather than an accept() loop on the Apache 1.3 performance tuning page.
Excerpt from that document:
“Ideally you should run servers without multiple Listen statements if you want the highest performance.”
We’ve been doing this for years at Yahoo! No, it’s not Rocket Science; it’s right there on Apache 1.3’s perf-tuning web page.
But there are many examples of SSL config files floating around out there with multiple Listen statements. If the rest of the world’s engineers are anything like me, there is a strong temptation to find a conf file that works and just use it. The copy-and-modify approach is great when all you want is functionality. But when performance matters, you’ve gotta read the docs.
While I agree with this in a large scale situation where you have enough volume of connections that this overhead matters, this argument ignores one major benefit of using virtual hosts: shared resources. If you have a box that can only easily support 200 concurrent apache children (due to memory footprint issues or backend database capacity, etc.), then without virtual hosts you have to make a preemptory judgement on how you want your resource caps to be set (100/100 children or 150/50 children, etc.). With virtual hosts, your serivices all pull from the common resource pool. Thus this demands less hands-on tuning for medium-sized sites.
If you are a high-traffic site, you have likely split your resources into SSL and non-SSL server clusters anyway.
I’ll add to what George said that this type of optimization all too often is a false economy. “Look we saved several milliseconds per 1000 request!” all while not caching Oracle connections or in some other way shooting yourself in the foot with a bazooka.
The easy optimizations rarely help nearly as much as the hard ones (getting the architecture right).
🙂
– ask
I guess I’d always like to see some benchmarks to justify configuration changes such as this for different scenarios. The convenience of using virtual hosts rather than implementing multiple server instances far outweights any minor performance improvements – which could just as easily come from changing some other web server configuration.
There are some decent Apache benchmarking server tools available, yet they hardly ever seem to be used. Or perhaps people do use them but just never bother to report any results.