14 ms·

The Architecture of Open Source Applications: Nginx

292 points by larsvegas_ 11y ago

losvedir 11y ago
Does anyone know how this architecture compares to cowboy? I know erlang is known for concurrency, but I'm assuming erlang isn't as fast as the custom-tailored C here. OTOH, I feel slightly less concerned about security issues with erlang.
- rdtsc 11y ago
  Well cowboy is an application library. So it is a bit in a different league. With cowboy you can start writing your business logic or application code directly and go to work. Nginx can do some of that with Lua integration but it is nice for serving static files and proxying to back-ends. I could see for example nginx in front of cowboy. It would strip away ssl, serve static pages, maybe authorization/authentication and then proxy connections to cowboy servers in the backend for application logic.
- biokoda 11y ago
  What's common is both are based on kqueue/epoll. Erlang then provides a very elegant interface on top of it.
jsprogrammer 11y ago
>These days the Internet is so widespread and ubiquitous it's hard to imagine it wasn't exactly there, as we know it, a decade ago. It has greatly evolved, from simple HTML producing clickable text, based on NCSA and then on Apache web servers, to an always-on communication medium used by more than 2 billion users worldwide. The Internet[0] has a much richer history and larger ecosystem than just the World Wide Web. The Internet started nearly six decades ago, the web has only been around for a bit more than two. [0] https://en.wikipedia.org/wiki/Internet https://en.wikipedia.org/wiki/Internet
- scott_karana 11y ago
  Yeah, I thought that was pretty damn breathless of the author too. Architecturally and usability-wise, we're more or less at the same place as a decade ago: In 2004, both nginx and Gmail were released, and people were going ape about exciting "Web 2.0" technologies like DHTML and AJAX, whose paradigms more or less still underpin all modern development. There have been a lot of additions and streamlinings, but "dynamic pages/apps in the browser without a pageload" were the modus operandi then, and are the MO now.
  - nkozyra 11y ago
    It's not readily apparent, but this item was written in 2012.
- deleted 11y ago
  [deleted]
anowlcalledjosh 11y ago
Why do web servers always seem to invent their own config file format? Whilst nginx seems to do it slightly more sanely than Apache, it still doesn't use something like YAML or JSON; is there a good/obvious reason for this I'm missing?
- rdtsc 11y ago
  JSON doesn't allow comments. So it is an ok-ish config format. Yaml would have been better. But they probably wrote everything from scratch to be optimized and decided if they are writing a parser for a config file might as well invent a config file format as well :-)
  - FooBarWidget 11y ago
    Nginx was invented before the days of JSON and YAML...
    - nkozyra 11y ago
      JSON, sure, but I think YAML pre-dated the launch of nginx (if not the initial development). https://groups.yahoo.com/neo/groups/sml-dev/conversations/topics/4710 https://groups.yahoo.com/neo/groups/sml-dev/conversations/to...
      - FooBarWidget 11y ago
        YAML initial release: 2001 Nginx initial release: 2004 Well ok. But I'd still argue that Nginx was invented before the popularization of YAML. I think I didn't see YAML until I got in touch with Rails in 2007, which used the format extensively. And even then, almost everyone I met didn't take it seriously, saying that it is a joke until Microsoft, IBM, etc support it.
  - CrLf 11y ago
    Not allowing comments doesn't make JSON an "ok-ish" config format, it makes it completely _unsuitable_ for it.
evincarofautumn 11y ago
No matter how many times I see “nginx”, and know that it’s supposed to be “engine X”, I always pronounce it as [ŋɪŋks] in my head! The way nginx handles requests and responses in an implicit event loop reminds me of a recent talk by Brian Kernighan, in which he mentions the ubiquity of the “pattern–action” model in many domains. I think it’s a very useful architectural pattern to have in mind when you’re designing a configuration system or a DSL. I also liked this quote: > …it is worth avoiding the dilution of development efforts on something that is neither the developer’s core competence or the target application.
- harterrt 11y ago
  Do you have a link to that talk? Sounds relevant to a side project I'm working on. Thanks!
  - robertelder 11y ago
    https://www.youtube.com/watch?v=Sg4U4r_AgJU&feature=youtu.be&t=21m19s https://www.youtube.com/watch?v=Sg4U4r_AgJU&feature=youtu.be...
- frenchy 11y ago
  Are you ESL (or bilingual)? I'm curious because word-initial [ŋ] is unpronounceable to most native English speakers.
  - evincarofautumn 11y ago
    I’m a native English speaker with a background in phonetics and a silly brain. I speak several languages very poorly. :) Rather like Larry Wall: > I started trying to teach myself Japanese about 10 years ago, and I could speak it quite well, because of my phonology and phonetics training–but it’s very hard for me to understand what anybody says. So I can go to Japan and ask for directions, but I can’t really understand the answers!
  - function_seven 11y ago
    For others like me who are phonetically-illiterate, [ŋ] is explained here: https://en.wikipedia.org/wiki/Velar_nasal https://en.wikipedia.org/wiki/Velar_nasal
arca_vorago 11y ago
While I like nginx over apache because I've been burned too many times by strange apache configs, I have recently found and am growing to love Hiawatha. It's a GPL webserver focused on security, uses PolarSSL which jut got bought out and is now mbed, and it's pretty fast. All the benchmarks I've seen show it comparable to stock nginx, apache, but once you tack on some of the optimizations nginx will beat Hiawatha. It also has a very easy config syntax. Just for anyone interested: https://www.hiawatha-webserver.org/ https://www.hiawatha-webserver.org/ The dev doesn't do much advertising, so word of mouth on a place like HN really helps.
- faeron 11y ago
  What optimizations are you talking about? And how do those beat Hiawatha?
  - arca_vorago 11y ago
    Well, I could have sworn I remember seeing a benchmark comparing stock vs basically tuned (config files) nginx, hiawatha, and a few others, where stock hiawatha won but tuned nginx beat it out, but I just spent ten minutes or so looking for it and couldn't find it, so I'm going to have to retract my earlier statement I suppose. Either way, I think Hiawatha is a great webserver that should get more attention. Especially since I am GPL proponent and Hiawatha is one of the only currently maintained GPL webservers. As a bonus here is a benchmark of nginx and hiawatha under attack. (notice the service drop on nginx) https://www.hiawatha-webserver.org/weblog/64 https://www.hiawatha-webserver.org/weblog/64
davidw 11y ago
> Although Apache provided a solid foundation for future development, it was architected to spawn a copy of itself for each new connection That's not really correct: https://httpd.apache.org/docs/2.2/mod/prefork.html https://httpd.apache.org/docs/2.2/mod/prefork.html Nginx makes it easier to handle a bunch of concurrent connections, but it's not as if Apache simply forks for each new connection.
- lobster_johnson 11y ago
  You're quoting from a paragraph that's summarizing the history of Apache, and the statement was true about Apache 1.x. Back in the day, Apache 2.0 took a long time to gain substantial market share, for various reasons. The situation was not too dissimilar from the current Python 2/3 split. Edit: But I guess Apache never forked for every connection, even in 1.3. It only forked if it needed a new child and the existing ones were busy.
  - davidw 11y ago
    > the statement was true about Apache 1.x. Apache 1.3 did not fork a process per connection. It forked to handle additional concurrent connections, but that's very different than forking for each and every connection.
davidmichael 11y ago
I wish there was more input as to why Apache 2.4 isn't suitable. It's been 3 years since its event driven model was released and it is a perfectly acceptable web server even for static content.
- Karb 11y ago
  Apache 2.4 isn't event driven. The Apache's Even MPM only handles keep-alive connections asynchronously, while the whole request processing is still synchronous. It solves only one problem of Apache, but it still doesn't make it as scalable as nginx.
  - pquerna 11y ago
    Hi, I'm one of the main authors (along with others, it is a community driven project) of the Event MPM for Apache. On Benchmarks and timelines: I agree that 2.2+ was not widely available for many years due to the update cycle of linux distributions, but at the time nginx wasn't in the distros... so it become a thing where people would yum install apache2, get a 2-5 year old version, and they would benchmark that against an ngnix from their latest dev download. The original work for the Event MPM started around 2004: http://mail-archives.apache.org/mod_mbox/httpd-dev/200411.mbox/%3C41868F73.9010602@force-elite.com%3E http://mail-archives.apache.org/mod_mbox/httpd-dev/200411.mb... The version in 2.2 was mostly focused on Keep-Alive requests. Apache 2.2.0 was first kicked out on December 1, 2005. To go beyond Keep-Alive requests, is a set of features/patches called "Async Write Completion". Much of this work was done in 2006-2007 by Graham Leggett: https://mail-archives.apache.org/mod_mbox/httpd-dev/201510.mbox/%3C28641C04-8936-4004-BA40-C889C8B7846A@sharp.fm%3E https://mail-archives.apache.org/mod_mbox/httpd-dev/201510.m... Timing wise, most of that work did not find its way into a stable release until 2.4, which came out February 17, 2012. This is the date the article references.
    - mwpmaybe 11y ago
      Thanks for your work on Apache. Do you recommend any published benchmarks of modern Apache vs. modern Nginx?
nisa 11y ago
I really enjoy nginx, as it's more flexible to configure but I've never understood why Apache got this slow label... FTA: In February 2012, the Apache 2.4.x branch was released to the public. Although this latest release of Apache has added new multi-processing core modules and new proxy modules aimed at enhancing scalability and performance, it's too soon to tell if its performance, concurrency and resource utilization are now on par with, or better than, pure event-driven web servers. It would be very nice to see Apache application servers scale better with the new version, though, as it could potentially alleviate bottlenecks on the backend side which still often remain unsolved in typical nginx-plus-Apache web configurations. I'm using Apache 2.4 with mpm_event + mod_proxy_fcgid and it's doing fine - 99% of the work and time spend is done in the FastCGI application anyway and for static content mpm_event is good enough. I wouldn't run a dedicated static CDN box on Apache but for everything that can run on a single server Apache can also do the job... even HTTP/2 with mod_h2 works fine as of 2.4.17 A problem with nginx is to figure out what matches in a complex config... it's not straightforward. .htaccess is nice and simple for a shared server with lot's of users. I really like nginx but I guess most people just don't really need it. Migrating to 2.4 and mpm_event should be good enough.
- DantesRequiem 11y ago
  Historical reasons...after nginx started blowing Apache's performance out of the water, Apache addressed some fundamental architectural issues and caught (mostly) up. As an example, I would refer you to a discussion down this thread about Apache 1.x forking for concurrent connections.
  - ryuuchin 11y ago
    Also just for context remember that on linux forking and threads are basically the same thing so you can't just switch out one for the other and expect performance to change (it won't).
    - WildUtah 11y ago
      "forking and threads are basically the same thing" It's nowhere near that simple. You can fork lightweight like threads or heavy. One of the terrible things about Apache performance was all the heavy forking on every single request for generated pages. That was back when it was really expensive.
jrochkind1 11y ago
> In February 2012, the Apache 2.4.x branch was released to the public. Although this latest release of Apache has added new multi-processing core modules and new proxy modules aimed at enhancing scalability and performance, it's too soon to tell if its performance, concurrency and resource utilization are now on par with, or better than, pure event-driven web servers. When was this written? Is it still too soon to tell? 2.5 years seems like enough time to tell?
- mwpmaybe 11y ago
  Math? 3.75 years?
alexandrerond 11y ago
Every "new" webserver tries to fix apache configuration syntax mess, and imho they all fail. Yes, setting up a reverse proxy looks simpler with nginx or haproxy for that matter. Now when it comes to complex configurations they all suck, and I'm not sure a json/yaml config format is going to fix that as long as webservers have such wide scopes (from serving static pages, to proxying traffic, authorizing, authenticating, encrypting...). At least apache is very modular on this regard and some credit should be given to it having survived and evolved along with all the newer options.
- sanderjd 11y ago
  The better choice is not a new webserver program with a different, possibly better, configuration language, it's HTTP server libraries that can be used from actual programming languages to do whatever you want. Many languages ship with really good libraries these days.
  - therein 11y ago
    They indeed are shipping with really good libraries these days but no matter how good they are, there is some level of doubt that they fail to alleviate and they get deployed behind nginx or apache httpd anyway.
    - sanderjd 11y ago
      It seems more like they are deployed behind load balancers, because load balancing is a specific job that it makes sense to do with a separate piece of software. Admittedly, that separate piece of software is often nginx, but there are other popular options, and I don't think very many people use Apache that way (though I could be wrong).
      - therein 11y ago
        I guess I should have said Apache Traffic Server rather than httpd. Their plugins and routing configuration is getting pretty enjoyable to work with.
deleted 11y ago
[deleted]
sinzone 11y ago
Lua support in nginx is phenomenal, especially when combined with LuaJIT. It basically allows to transform nginx into an application server and run arbitrary code that can pretty much do anything. I would like to mention agentzh and his team that did an amazing job in releasing OpenResty[1] which makes it easy to extend nginx with custom Lua functionality, which also happens to be the backbone of CloudFlare architecture, and the core technology being used by projects like Kong[2] when it comes to microservices management. [1] http://openresty.org/ http://openresty.org/ [2] https://github.com/Mashape/kong https://github.com/Mashape/kong
- kator 11y ago
  +1 I built a nginx+luajit RTB bidder that did 168k qps on 8 cores. It smashed the C eventlib version and of course it crushed the Java version. Golang came in a close second but at the time with 8 cores I had to do crazy things to get it to pin to CPU's since the golang thread scheduling didn't seem very scaleable beyond 4 cores.
  - lpgauth 11y ago
    168K/s? Did you actually decode the bid request (json) or just return no bid? That seems too good to be true.
    - fit2rule 11y ago
      I also would love to know details about this .. very impressive stats!
      - royjacobs 11y ago
        These bidding platforms typically don't provide you with JSON but with some headers or query parameters that are very quick to parse (especially for the native nginx code), so your Lua code can basically boil down to a few table lookups.
        11y ago
DonnyV 11y ago
I love using nginx but it seems that all the new features lately are only accessible through their enterprise service.
- gamesbrainiac 11y ago
  Nginx is a solid piece of software with a lot of people working on it. I find it sad that people expect good services built on top of it to be free as well. Without an enterprise/paid offering how else do you suppose people fund nginx? Right now the state of open source funding is abysmal.
  - nileshtrivedi 11y ago
    His point is that all this funding is not leading to any new features in the open-source version.
    - gamesbrainiac 11y ago
      Just maintaining a project as large as nginx is hard enough, and takes a lot of people to do it.
    - Karb 11y ago
      Are you joking? Check the changelog of the open-source version. http://nginx.org/en/CHANGES http://nginx.org/en/CHANGES
      - pnommensen 11y ago
        It's a common question. As you correctly noted in the changelog, the vast majority of features have been placed in the open source version. The commercial product has gained great visibility and adoption but open source NGINX is very core to our company. In fact, development and feature releases to open source NGINX have rapidly increased since the inception of NGINX, Inc (the company) because it can support the development efforts :) (disclaimer: I work at NGINX.)
gtrubetskoy 11y ago
Back when I was tinkering with mod_python performance[0] there was this web server called nxweb[1], which out-performed nginx consistently by quite a bit. [0] http://grisha.org/blog/2013/11/07/mod-python-performance-revisited/ http://grisha.org/blog/2013/11/07/mod-python-performance-rev... [1] https://bitbucket.org/yarosla/nxweb/overview https://bitbucket.org/yarosla/nxweb/overview
ferbivore 11y ago
Sort of unrelated, but I would love to see one of these for Unreal Engine. If there's an internal architecture overview somewhere, I haven't found it.
maattdd 11y ago
More impressive in the same book, how another server (Warp) written in Haskell (GCed lazy functional language, supposedly way slower than C over epoll) achieves the same performance as nginx! http://www.aosabook.org/en/posa/warp.html http://www.aosabook.org/en/posa/warp.html

292 points by larsvegas_ 11y ago

Does anyone know how this architecture compares to cowboy? I know erlang is known for concurrency, but I'm assuming erlang isn't as fast as the custom-tailored C here. OTOH, I feel slightly less concerned about security issues with erlang.

rdtsc 11y ago
Well cowboy is an application library. So it is a bit in a different league. With cowboy you can start writing your business logic or application code directly and go to work. Nginx can do some of that with Lua integration but it is nice for serving static files and proxying to back-ends. I could see for example nginx in front of cowboy. It would strip away ssl, serve static pages, maybe authorization/authentication and then proxy connections to cowboy servers in the backend for application logic.
biokoda 11y ago
What's common is both are based on kqueue/epoll. Erlang then provides a very elegant interface on top of it.

jsprogrammer 11y ago

>These days the Internet is so widespread and ubiquitous it's hard to imagine it wasn't exactly there, as we know it, a decade ago. It has greatly evolved, from simple HTML producing clickable text, based on NCSA and then on Apache web servers, to an always-on communication medium used by more than 2 billion users worldwide. The Internet[0] has a much richer history and larger ecosystem than just the World Wide Web. The Internet started nearly six decades ago, the web has only been around for a bit more than two. [0] https://en.wikipedia.org/wiki/Internet https://en.wikipedia.org/wiki/Internet

scott_karana 11y ago
Yeah, I thought that was pretty damn breathless of the author too. Architecturally and usability-wise, we're more or less at the same place as a decade ago: In 2004, both nginx and Gmail were released, and people were going ape about exciting "Web 2.0" technologies like DHTML and AJAX, whose paradigms more or less still underpin all modern development. There have been a lot of additions and streamlinings, but "dynamic pages/apps in the browser without a pageload" were the modus operandi then, and are the MO now.
- nkozyra 11y ago
  It's not readily apparent, but this item was written in 2012.
deleted 11y ago
[deleted]

anowlcalledjosh 11y ago

Why do web servers always seem to invent their own config file format? Whilst nginx seems to do it slightly more sanely than Apache, it still doesn't use something like YAML or JSON; is there a good/obvious reason for this I'm missing?

rdtsc 11y ago
JSON doesn't allow comments. So it is an ok-ish config format. Yaml would have been better. But they probably wrote everything from scratch to be optimized and decided if they are writing a parser for a config file might as well invent a config file format as well :-)
- FooBarWidget 11y ago
  Nginx was invented before the days of JSON and YAML...
  - nkozyra 11y ago
    JSON, sure, but I think YAML pre-dated the launch of nginx (if not the initial development). https://groups.yahoo.com/neo/groups/sml-dev/conversations/topics/4710 https://groups.yahoo.com/neo/groups/sml-dev/conversations/to...
    - FooBarWidget 11y ago
      YAML initial release: 2001 Nginx initial release: 2004 Well ok. But I'd still argue that Nginx was invented before the popularization of YAML. I think I didn't see YAML until I got in touch with Rails in 2007, which used the format extensively. And even then, almost everyone I met didn't take it seriously, saying that it is a joke until Microsoft, IBM, etc support it.
- CrLf 11y ago
  Not allowing comments doesn't make JSON an "ok-ish" config format, it makes it completely _unsuitable_ for it.

evincarofautumn 11y ago

No matter how many times I see “nginx”, and know that it’s supposed to be “engine X”, I always pronounce it as [ŋɪŋks] in my head! The way nginx handles requests and responses in an implicit event loop reminds me of a recent talk by Brian Kernighan, in which he mentions the ubiquity of the “pattern–action” model in many domains. I think it’s a very useful architectural pattern to have in mind when you’re designing a configuration system or a DSL. I also liked this quote: > …it is worth avoiding the dilution of development efforts on something that is neither the developer’s core competence or the target application.

harterrt 11y ago
Do you have a link to that talk? Sounds relevant to a side project I'm working on. Thanks!
- robertelder 11y ago
  https://www.youtube.com/watch?v=Sg4U4r_AgJU&feature=youtu.be&t=21m19s https://www.youtube.com/watch?v=Sg4U4r_AgJU&feature=youtu.be...
frenchy 11y ago
Are you ESL (or bilingual)? I'm curious because word-initial [ŋ] is unpronounceable to most native English speakers.
- evincarofautumn 11y ago
  I’m a native English speaker with a background in phonetics and a silly brain. I speak several languages very poorly. :) Rather like Larry Wall: > I started trying to teach myself Japanese about 10 years ago, and I could speak it quite well, because of my phonology and phonetics training–but it’s very hard for me to understand what anybody says. So I can go to Japan and ask for directions, but I can’t really understand the answers!
- function_seven 11y ago
  For others like me who are phonetically-illiterate, [ŋ] is explained here: https://en.wikipedia.org/wiki/Velar_nasal https://en.wikipedia.org/wiki/Velar_nasal

arca_vorago 11y ago

While I like nginx over apache because I've been burned too many times by strange apache configs, I have recently found and am growing to love Hiawatha. It's a GPL webserver focused on security, uses PolarSSL which jut got bought out and is now mbed, and it's pretty fast. All the benchmarks I've seen show it comparable to stock nginx, apache, but once you tack on some of the optimizations nginx will beat Hiawatha. It also has a very easy config syntax. Just for anyone interested: https://www.hiawatha-webserver.org/ https://www.hiawatha-webserver.org/ The dev doesn't do much advertising, so word of mouth on a place like HN really helps.

faeron 11y ago
What optimizations are you talking about? And how do those beat Hiawatha?
- arca_vorago 11y ago
  Well, I could have sworn I remember seeing a benchmark comparing stock vs basically tuned (config files) nginx, hiawatha, and a few others, where stock hiawatha won but tuned nginx beat it out, but I just spent ten minutes or so looking for it and couldn't find it, so I'm going to have to retract my earlier statement I suppose. Either way, I think Hiawatha is a great webserver that should get more attention. Especially since I am GPL proponent and Hiawatha is one of the only currently maintained GPL webservers. As a bonus here is a benchmark of nginx and hiawatha under attack. (notice the service drop on nginx) https://www.hiawatha-webserver.org/weblog/64 https://www.hiawatha-webserver.org/weblog/64

davidw 11y ago

> Although Apache provided a solid foundation for future development, it was architected to spawn a copy of itself for each new connection That's not really correct: https://httpd.apache.org/docs/2.2/mod/prefork.html https://httpd.apache.org/docs/2.2/mod/prefork.html Nginx makes it easier to handle a bunch of concurrent connections, but it's not as if Apache simply forks for each new connection.

lobster_johnson 11y ago
You're quoting from a paragraph that's summarizing the history of Apache, and the statement was true about Apache 1.x. Back in the day, Apache 2.0 took a long time to gain substantial market share, for various reasons. The situation was not too dissimilar from the current Python 2/3 split. Edit: But I guess Apache never forked for every connection, even in 1.3. It only forked if it needed a new child and the existing ones were busy.
- davidw 11y ago
  > the statement was true about Apache 1.x. Apache 1.3 did not fork a process per connection. It forked to handle additional concurrent connections, but that's very different than forking for each and every connection.

davidmichael 11y ago

I wish there was more input as to why Apache 2.4 isn't suitable. It's been 3 years since its event driven model was released and it is a perfectly acceptable web server even for static content.

Karb 11y ago
Apache 2.4 isn't event driven. The Apache's Even MPM only handles keep-alive connections asynchronously, while the whole request processing is still synchronous. It solves only one problem of Apache, but it still doesn't make it as scalable as nginx.
- pquerna 11y ago
  Hi, I'm one of the main authors (along with others, it is a community driven project) of the Event MPM for Apache. On Benchmarks and timelines: I agree that 2.2+ was not widely available for many years due to the update cycle of linux distributions, but at the time nginx wasn't in the distros... so it become a thing where people would yum install apache2, get a 2-5 year old version, and they would benchmark that against an ngnix from their latest dev download. The original work for the Event MPM started around 2004: http://mail-archives.apache.org/mod_mbox/httpd-dev/200411.mbox/%3C41868F73.9010602@force-elite.com%3E http://mail-archives.apache.org/mod_mbox/httpd-dev/200411.mb... The version in 2.2 was mostly focused on Keep-Alive requests. Apache 2.2.0 was first kicked out on December 1, 2005. To go beyond Keep-Alive requests, is a set of features/patches called "Async Write Completion". Much of this work was done in 2006-2007 by Graham Leggett: https://mail-archives.apache.org/mod_mbox/httpd-dev/201510.mbox/%3C28641C04-8936-4004-BA40-C889C8B7846A@sharp.fm%3E https://mail-archives.apache.org/mod_mbox/httpd-dev/201510.m... Timing wise, most of that work did not find its way into a stable release until 2.4, which came out February 17, 2012. This is the date the article references.
  - mwpmaybe 11y ago
    Thanks for your work on Apache. Do you recommend any published benchmarks of modern Apache vs. modern Nginx?

nisa 11y ago

I really enjoy nginx, as it's more flexible to configure but I've never understood why Apache got this slow label... FTA: In February 2012, the Apache 2.4.x branch was released to the public. Although this latest release of Apache has added new multi-processing core modules and new proxy modules aimed at enhancing scalability and performance, it's too soon to tell if its performance, concurrency and resource utilization are now on par with, or better than, pure event-driven web servers. It would be very nice to see Apache application servers scale better with the new version, though, as it could potentially alleviate bottlenecks on the backend side which still often remain unsolved in typical nginx-plus-Apache web configurations. I'm using Apache 2.4 with mpm_event + mod_proxy_fcgid and it's doing fine - 99% of the work and time spend is done in the FastCGI application anyway and for static content mpm_event is good enough. I wouldn't run a dedicated static CDN box on Apache but for everything that can run on a single server Apache can also do the job... even HTTP/2 with mod_h2 works fine as of 2.4.17 A problem with nginx is to figure out what matches in a complex config... it's not straightforward. .htaccess is nice and simple for a shared server with lot's of users. I really like nginx but I guess most people just don't really need it. Migrating to 2.4 and mpm_event should be good enough.

DantesRequiem 11y ago
Historical reasons...after nginx started blowing Apache's performance out of the water, Apache addressed some fundamental architectural issues and caught (mostly) up. As an example, I would refer you to a discussion down this thread about Apache 1.x forking for concurrent connections.
- ryuuchin 11y ago
  Also just for context remember that on linux forking and threads are basically the same thing so you can't just switch out one for the other and expect performance to change (it won't).
  - WildUtah 11y ago
    "forking and threads are basically the same thing" It's nowhere near that simple. You can fork lightweight like threads or heavy. One of the terrible things about Apache performance was all the heavy forking on every single request for generated pages. That was back when it was really expensive.

jrochkind1 11y ago

> In February 2012, the Apache 2.4.x branch was released to the public. Although this latest release of Apache has added new multi-processing core modules and new proxy modules aimed at enhancing scalability and performance, it's too soon to tell if its performance, concurrency and resource utilization are now on par with, or better than, pure event-driven web servers. When was this written? Is it still too soon to tell? 2.5 years seems like enough time to tell?

mwpmaybe 11y ago
Math? 3.75 years?

alexandrerond 11y ago

Every "new" webserver tries to fix apache configuration syntax mess, and imho they all fail. Yes, setting up a reverse proxy looks simpler with nginx or haproxy for that matter. Now when it comes to complex configurations they all suck, and I'm not sure a json/yaml config format is going to fix that as long as webservers have such wide scopes (from serving static pages, to proxying traffic, authorizing, authenticating, encrypting...). At least apache is very modular on this regard and some credit should be given to it having survived and evolved along with all the newer options.

sanderjd 11y ago
The better choice is not a new webserver program with a different, possibly better, configuration language, it's HTTP server libraries that can be used from actual programming languages to do whatever you want. Many languages ship with really good libraries these days.
- therein 11y ago
  They indeed are shipping with really good libraries these days but no matter how good they are, there is some level of doubt that they fail to alleviate and they get deployed behind nginx or apache httpd anyway.
  - sanderjd 11y ago
    It seems more like they are deployed behind load balancers, because load balancing is a specific job that it makes sense to do with a separate piece of software. Admittedly, that separate piece of software is often nginx, but there are other popular options, and I don't think very many people use Apache that way (though I could be wrong).
    - therein 11y ago
      I guess I should have said Apache Traffic Server rather than httpd. Their plugins and routing configuration is getting pretty enjoyable to work with.

deleted 11y ago

[deleted]

sinzone 11y ago

Lua support in nginx is phenomenal, especially when combined with LuaJIT. It basically allows to transform nginx into an application server and run arbitrary code that can pretty much do anything. I would like to mention agentzh and his team that did an amazing job in releasing OpenResty[1] which makes it easy to extend nginx with custom Lua functionality, which also happens to be the backbone of CloudFlare architecture, and the core technology being used by projects like Kong[2] when it comes to microservices management. [1] http://openresty.org/ http://openresty.org/ [2] https://github.com/Mashape/kong https://github.com/Mashape/kong

kator 11y ago
+1 I built a nginx+luajit RTB bidder that did 168k qps on 8 cores. It smashed the C eventlib version and of course it crushed the Java version. Golang came in a close second but at the time with 8 cores I had to do crazy things to get it to pin to CPU's since the golang thread scheduling didn't seem very scaleable beyond 4 cores.
- lpgauth 11y ago
  168K/s? Did you actually decode the bid request (json) or just return no bid? That seems too good to be true.
  - fit2rule 11y ago
    I also would love to know details about this .. very impressive stats!
    - royjacobs 11y ago
      These bidding platforms typically don't provide you with JSON but with some headers or query parameters that are very quick to parse (especially for the native nginx code), so your Lua code can basically boil down to a few table lookups.
      - 11y ago

DonnyV 11y ago

I love using nginx but it seems that all the new features lately are only accessible through their enterprise service.

gamesbrainiac 11y ago
Nginx is a solid piece of software with a lot of people working on it. I find it sad that people expect good services built on top of it to be free as well. Without an enterprise/paid offering how else do you suppose people fund nginx? Right now the state of open source funding is abysmal.
- nileshtrivedi 11y ago
  His point is that all this funding is not leading to any new features in the open-source version.
  - gamesbrainiac 11y ago
    Just maintaining a project as large as nginx is hard enough, and takes a lot of people to do it.
  - Karb 11y ago
    Are you joking? Check the changelog of the open-source version. http://nginx.org/en/CHANGES http://nginx.org/en/CHANGES
    - pnommensen 11y ago
      It's a common question. As you correctly noted in the changelog, the vast majority of features have been placed in the open source version. The commercial product has gained great visibility and adoption but open source NGINX is very core to our company. In fact, development and feature releases to open source NGINX have rapidly increased since the inception of NGINX, Inc (the company) because it can support the development efforts :) (disclaimer: I work at NGINX.)

gtrubetskoy 11y ago

Back when I was tinkering with mod_python performance[0] there was this web server called nxweb[1], which out-performed nginx consistently by quite a bit. [0] http://grisha.org/blog/2013/11/07/mod-python-performance-revisited/ http://grisha.org/blog/2013/11/07/mod-python-performance-rev... [1] https://bitbucket.org/yarosla/nxweb/overview https://bitbucket.org/yarosla/nxweb/overview

ferbivore 11y ago

Sort of unrelated, but I would love to see one of these for Unreal Engine. If there's an internal architecture overview somewhere, I haven't found it.

maattdd 11y ago

More impressive in the same book, how another server (Warp) written in Haskell (GCed lazy functional language, supposedly way slower than C over epoll) achieves the same performance as nginx! http://www.aosabook.org/en/posa/warp.html http://www.aosabook.org/en/posa/warp.html