I use both, on different sites.

I doubt the choice of server will make much difference to dynamic pages. Unless you are serving lot of requests for static files, it probably does not matter.

Apache does have a choice of workers, so you should not be pre-forking these days unless you need to run non-threadsafe code within the Apache worker. It used to be the case with mod_php, for example.

Caddy is slower than Nginx, so I doubt its going to perform better than Apache with event mpm

Litespeed advocates like to quote benchmarks produced by lightspeed.

if it aint broke dont fix it.

Nginx is popular with large scale users - cloudflare used to use and sponsor Openresty which is Nginx based.

You prompted me to look at Lighttpd as I used to use it. I stopped because development had slowed.

It seems to have gained quite a few features and being maintained well and I always found it easy to configure (YMMV!).

I use both, in one case even on the same website, the main content runs on Apache and a subsection is proxied to another server that runs Nginx.
I prefer Nginx.

but as mentioned above:

I doubt the choice of server will make much difference to dynamic pages.

I don't worry too much about the server, as I spend most of my time focused on the application layer. Technically when I do use Nginx, it is used as a proxy. If I'm running a Python backend I'll use something like Hypercorn (async implementation of Gunicorn) as the server.

I use Apache on most general sites and haproxy for load balancing. Everything is running on Centos 7, even the ARM servers (Raspberry PI 3B+) I have in the field. Just a matter of convenience because the config files are all in the same location.

I run the newest Apache and PHP from third party repositories though, because the default Centos 7 Apache is too old to support HTTP/2. It it is one of the problems with the RHEL/Centos family. The server environment is rock-solid but the applications are often outdated.

Haproxy is both used for the front-end HTTP load-balancing/failover and the back-end MySQL load-balancing/failover from the web servers to the database cluster.

I have a few high-performance servers running Golang as web-server to a compiled back-end application. Properly built, a multi-tasking Golang web-application blows away every single-threaded scripted application running on a LAMP stack (where the P in LAMP is either PHP, Perl or Python)

Properly built, a multi-tasking Golang web-application blows away every single-threaded scripted application running on a LAMP stack (where the P in LAMP is either PHP, Perl or Python)

There is an awful lot of it depends in whether one language performs better than another. I do not really use the other two languages but for a "slow" language Python can perform well. Python can certainly be multi tasking using multiple processes or multiple threads. You also have the option of async.

You can also use C libraries, re-write performance critical code in Cython, use a faster Python implementation such as PyPy etc. What you would do would depend on what your performance problem is.

A lot of web apps spend most of their time waiting for the database to respond so app performance may be determined primarily by database optimisation anyway. I have written things like API endpoints that use a complex query to get data from the database, then pass it to another C library to encode it as JSON, and then returns that, with minimal processing between those steps.

Another factor. We are an old school crowd here and tend to assume delivering the page HTML fast is what matters.

A lot websites load a lot of static assets: front end frameworks, and fonts , analytics scripts etc. and those dominate loading time anyway. A lot of the time combining and minifying those will probably do a lot more than changing servers, as would making sure HTTP/2 is enabled (to allow more parallel loading).

A lot websites load a lot of static assets: front end frameworks, and fonts , analytics scripts etc. and those dominate loading time anyway.

Long may they continue to so do. I do so love the smell of competitive advantage morning, noon, and night!

There is no one method fits all requirements all capabilities. Which was my (curiosity) reason for thread: what are others using and why. The why not to snicker but to see if I might be overlooking something of potential benefit. To me in my situation. For you in yours.

This is not the first time a similar question has been asked on WebmasterWorld, as we know all too well ‘things’ in our business change all too frequently.

Fascinating as usual. :)
Thanks much.

@iamlost, unfortunately I often have to try to talk clients (and designers they have hired) out of adding a million external scripts.

I think the other thing is that it can be quite difficult to know which is best. I once came across a good answer to the question of which server was more secure (I think that was in a discussion about Hiawatha, which is designed to be more secure): the one you know how to configure securely is the most secure for you.

I think the same for performance tuning, although maybe less so - I am pretty sure that Nginx will be better than Apache for static files on a very busy site, for example.

At the moment this conversation has made me question some decisions (I suppose its a good thing, but it does not feel like it right now :) ). May be I should have used Nginx on one site where I used Apache, and maybe Apache would have been better on another site. Perhaps I should have carried on using Lighttpd as development seems to have been more active than I expected and I find it easier to configure. etc.

Ah, a bit of a correction to what I use...

As stated I use HAProxy in front of Apache on Debian
However
I actually use both
Apache Traffic Server as a reverse proxy server for cached static pages
And
Apache HTTP as web server (and dynamic pages)
Then
HAProxy and PgBouncer in front of PostgreSQL

I’ve just got into the habit of thinking of the two Apaches as singular.

As lammert it’s a high availability failover methodology.

I switched from PHP to C++ mainly because I already knew C++ and the speed optimisation advantage is substantial. That said, if I didn’t know C++ I’d not have bothered given time and learning curve required.

Note: same reason I initially played with TensorFlo - C++ - and stayed despite some advantages with Torch, learning Python just wasn’t in the time available must acquire needs category.

Time is always the greatest constraint. We make work what we have within existing capabilities unless an alternative’s benefits greatly exceeds required investment time.
Or we are addicted to wandering down intriguing rabbit holes... and fall ever more behind the ever growing todo list...

There are so many options, especially in languages, and the objective/subjective benefit ratios keep changing, that often old school is a relaxing restful place.

When it comes to knowledge I’m the grubby kid with his nose pressed up against the glass of the candy store, toy store, book shop... so many wonderful wonders...
How did it get so late so soon?
Its night before its afternoon.
December is here before its June.
My goodness how the time has flewn.
How did it get so late so soon?
—-A Pocket Poem, Dr. Seuss

I've been running Apache is various •sandwich• configurations for close to 20 years and couldn't be happier with it.
Nginx is fine but it's nothing special on it's own – the OSS Nginx lacks features when compared to HAProxy, while at the same is less flexible as a web server when compared to Apache.

On Debian I have Apache behind HAProxy and Varnish, while on CeontOS I have Nginx and Varnish in front of Apache. So I get best of everything and can cover various use-cases when necessary.

The good old HAProxy->Varnish->Apache combo leaves the OSS Nginx in the dust for most of my projects.

For simple, mostly static projects, I am fine with either Apache or Nginx.