I'm one of those who always just stuck with Apache because 1) I'm used to it, and 2) it's never been close to a bottleneck in our stack. Especially now that the vast majority of static content requests don't even hit the servers at all. Buy I am curious! I haven't looked at comparisons in years, but last I did, everyone liked to compare nginx to prefork Apache, which is pointless.
Its like having the same waiter vs a pool of waiters
Sources: https://serverguy.com/wp-content/uploads/2020/10/Apache-Vs-N...
https://www.google.com/search?rlz=1C1CHBF_enUS874US874&sxsrf...
People sometimes like to have opinions about stuff. But there's no reason to google for secondary sources when the documentation is good.
Read the manual instead. The documentation for both projects is correct, short and to the point. They are both multi threaded, multi process, with an event loop. The documentation describes how to set those parameters. Look at the thread_pool directive for nginx and AsyncRequestWorkerFactor for Apache for example.
You could of course configure one thread per connection, but that only makes sense under specific circumstances.
TLS kills this, alas, and, I think, with TLS OpenSSL will be bottleneck for static content, not server.
OK. But you might as well use a fast setup if there's no cost in complexity to do so.
Since then computers (and presumably also Apache) have become faster and I don't really know how it compares today, but at least in the past it really did make a significant enough performance difference to care about.
Which use case is that?
What do you try to imply with your statement?
FLOSS licenses allow software to be used for any purpose. This is a good thing, after seeing lists of "undesireable countries" in EULAs.
Source? I fail to see any similarities between the two.
https://news.ycombinator.com/item?id=520077
Was it not? I find it hard to find sources, but I realllllly remember it started off as a heavily modified fork of Apache 1.3.
> nginx is not Apache fork. I know well enough Apache 1.3 and I've got some ideas from Apache such as memory pools, configuration methods, processing phases, etc., but there is no line of Apache code. As to OCSP, I'm going to implement it in the next 2.0 version.
edit: Assuming "brianm" is Brian McCallister, he would be a former ASF board member. If "jimjag" is Jim Jagielski, that would be one of the ASF founders.
not a bad sum for apache 1.3 fork...
In 2019, Rambler tried to take over Nginx claiming dubious copyright infringement, putting the main author [https://en.wikipedia.org/wiki/Igor_Sysoev|Igor Sysoev(w)] at risk.
https://news.ycombinator.com/item?id=520077
Was it not? I find it hard to find sources, but I realllllly remember it started off as a heavily modified fork of Apache 1.3.
I don't know that he was trying to imply anything. But I find it useful information, since there are lots of companies with IT Security departments that will more heavily scrutinized software based on its geographic origin.
When I joined my company, one of the first things I was tasked with was determining the origin of all of the software installed by my predecessor. Some of it got chucked out because it was from certain places.
And this was looong before anyone started dropping bombs in Kyiv.
It's not weird for a company in the UK to favor UK software, or a company in Japan to favor Japanese software, etc.
Did you learn from chatGPT how to convicingly tell completely made up and false information?
What part do you think is wrong? I must say you are quite creative with insults. Great skill!
Antisemitism is often referred to as "racism" and the specific domain of the word "Russian" is varied from person to person, so thanks for nitpick I guess?
In any case, I was referring to that specific "evil ${ethnicity/nationality/culture}" trope, tracing back to the day when Belarus and Ukraine had also been referred to as "Russians"
> replace with whatever nationality you like.
It has a ring of "evil Jews" to it. That's the replacement placeholder I use as a benchmark of wether something is appropriate to say out-loud.
Not ONCE have I had any negative experience, invasion of my privacy, with any russian product.
The only negativity I experienced was caused by services I pay for (as a German) being blocked because I was in Russia.
I strongly urge people to reconsider that the Russian people are not evil, and that Russian intelligence services do not give a fuck about random people using services in Russia. Now consider that Nginx is not in Russia, its open source, and quickly it becomes clear that this whole discussion is motivated only by a boogie-man type fearmongering and nothing else.
You should be much more afraid of any tech that isnt open source, that you use, than this.
Apologies for the tone - I am just very sick and tired of this kind of talk, and as a German it reminds me of what we read in our own history books about inducing fear based on where one is from.
Very sad times await us if people will start forming their opinions based On what chatgpt hallucinates to them or what they find from quick skim of wikipedia page
Guess what, ape: Google has russian connection too (Sergey Brin) and even your chemistry books have russian connection (Mendeleev)
While setting up Apache 2.4, I came to like certain things about it. For example, https://httpd.apache.org/docs/2.4/mod/mod_macro.html. Configuration seems in general less footgun-y than that of nginx (see https://news.ycombinator.com/item?id=30435282). I have also adopted https://tcl.apache.org/rivet/ and use it on the LAN server where someone else might reach for PHP. It is admittedly quite niche.
I'd love to be shown a better way on that, but Apache did rack up a W for that one use case.
> Since then https://github.com/mholt/caddy-webdav has come out for Caddy.
It turns out that Matt Holt published the WebDAV plugin a short time before the launch of Caddy 2. I didn't know this. I only found out about the plugin later.
> Caddy 2, my go-to HTTP server, lacked a WebDAV plugin at the time.
It wasn't, and it didn't. This was in 2019, and Caddy 2 launched in 2020. I was still only using Caddy 1 when I tested nginx and then Apache. Caddy 1 actually had an unofficial WebDAV plugin, https://github.com/hacdias/caddy-v1-webdav, which I remember finding a compatibility reason to not use.
> like fresh snow under foehn
I am from none of those places, speak no relevant languages other than English, and I had no trouble with the phrase in question.
I appreciate your effort in trying to stick up for me, though (: Perhaps if you want to be more helpful for those people who do conform to your assumptions, you could share a definition, in addition to your criticism.
"Fohn, an Englosh derivate of 'foehn', means 'a warm, dry wind', and is known for being particularly effective at melting snow."
Which coincidentally happens to have a similar contention as standing on fresh snow compacts it, but only from the comments did I guess it was supposed to be a melting analogy.
* applications are built to change them dynamically, making them part of application code, instead of you know... just having proper request router in app
* It is not "enter URL in, get rewritten URL out". You can do conditionals based on existence of files and a bunch of other stuff which means it can't be isolated from the app overusing it easily
Rewriting on loadbalancer to mangle some paths is to be avoided but overall not too bad to manage but what can happen in mod_rewrite by badly designed apps make app basically glued in into apache.
if (st && S_ISREG(st->st_mode)) return HANDLER_GO_ON;
Change it to if (st) without a regular file check, and it works as expected (great) with frameworks like Joomla etc (/administrator URLs, for example)
It had not seen any bugfix releases for quite a long time at that point, and nginx was available by then, so I made the swap. I continued to serve that website off of a single server for the rest of its lifetime.
nginx is very powerful and fast.
nginx could send static file with one syscall and zero-copy if OS supports it. It could exploit all system async mechanisms - POSIX AIO, kqueue, whatever you have. Linux was worst in this regards before io_uring, and FreeBSD or Solaris were much, much better platform for nginx.
For example, Igor Sysoev (mastermide behind nginx) pushed patches to FreeBSD kernel to shave off one syscall per file on this system.
Now, when everything is HTTPS, Linux have io_uring and Igor left nginx after F5 acquisition, it is not very useful - nginx is stagnating, support for KTLS is absent, support for io_uring on Linux is absent (though there are some forks and patches for this)...
But compare nginx and lighttpd is simply stupid, it is apples-to-oranges comparison.
Each one has its niche, of course.
Even Youtube used Lighttpd at some point.
Both are http servers, and lighttpd came out before Nginx, they both tried to solve the c10k problem.
nginx is at: 26% Apache is at 20%
It doesn't sound like nginx is even close to having this wrapped up; which is a really good thing because I've tried nginx and the config and design sucks. Apache does so many things well.
Personally I use apache as I have very few users (internal facing stuff), it has a nice simple mod_auth_openidc config which remains the same from one year to the next
I do have to recompile ws_tunnel though as I proxy a broken product I proxy which doesn't accept the correct standard for camel-capped "WebSocket" -- my "fix" script runs
sed -i 's/WebSocket/websocket/g' ./modules/proxy/mod_proxy_wstunnel.c
and recompiles
From the wiki.
Eh, the prefork engine isn't awful. It's not without limitations, but it's an excellent fit for some loads and a bad/terrible fit for others.
The main limitations are:
The child ramping behavior: you should set MinChildren = MaxChildren = StartChildren. Ramping children on demand sounds nice, but it's easy to run out of memory when all the children start or spend too much time on childinit instead of serving requests.
Anytime the child spends connected to a client socket but not actively working. Some of this can be mitigated. Turning off http keepalive (or handling it elsewhere) and setting large socket buffers allows the server to generate a response, give it to the kernel, and move on to the next client. If you're often waiting significantly for disk i/o, Apache pre-fork isn't a good fit.
Http keep-alive is a big deal for some uses, Yahoo had a nice hack for that, which I don't think made it out: have sockets wait for complete requests in another process, and send those sockets to apache over a unix socket; after apache is done with it, send it back to the 'cheapalive' daemon. That adds a bit of complexity, and I don't know of a public implementation, so not super useful to people, but it's possible to build.
I personally think prefork apache + mod_php is simpler than some other daemon + fastcgi php. But that's debatable.
Edit: oh and one more... .htaccess is clearly a performance suck. Perhaps a useful one depending on your application, but there's good reasons nobody else does it.
Another note on this 10 years anniversary is that, though Apache 2.4 was released in 2012-01, it was a rushed release and some features were still lacking. In my opinion, the most important was that mod_proxy could not talk to unix sockets. It made Apache 2.4 hard to use in many cases. This feature only appeared with 2.4.7 in 2013-09.
Nowadays I rarely see Apache installed on web servers that I work with. In one case, it was because the sysadmin was used to it (though 2.4 broke the compatibility with 2.2's config syntax), he didn't consider changing and even kept the awful Apache prefork engine. In other cases, it was because of some modules (e.g. shibboleth) that were packaged by the OS for Apache, but not for Nginx.