9 ms·
For my style of coding, and I think many others, Nginx has become dominant because it enables fast reverse proxy. And I think for many large websites it ahs bec
by lkrubner 13y ago
For my style of coding, and I think many others, Nginx has become dominant because it enables fast reverse proxy. And I think for many large websites it ahs become common to build websites out of many small apps, which run on different ports and which Nginx then knits together.
An example. Assuming you have the domain “example.com” then you might have an app that handles user login and you spin that up on, say, port 30000 and you map it to port 80 such that is appears as:
http://www.example.com/login http://www.example.com/login
You might also have an app that handles user signups which you spin up on port 30001 and you map to port 80 such that it appears as:
http://www.example.com/signup http://www.example.com/signup
You might also have an admin app that you spin up on port 30002 and you map to
http://admin.example.com/ http://admin.example.com/
You might also have an app that allows users to update their profile information and you spin that up on port 30003 and map that to
http://www.example.com/profile http://www.example.com/profile
And you might have an app that publishes much of your content as static HTML files, which you spin up on no port, as it does not accept TCP/IP requests — instead it queries the database and then creates static html files, which you save to some directory such as /var/www/example.com/public_html/ and you map that to
http://www.example.com/ http://www.example.com/
You can see how this gives the sysadmins a lot of freedom to spread load across servers in creative ways — if 1 app becomes especially popular, or resource hungry, the sysadmins can rather easily move it to its own server (or set of servers). This is one of the main reasons most big sites move to an architecture like this — it facilitates fine grained control of what sort of requests go to a particular server.
This is a flexible style and it allows small, maintainable apps. By contrast, consider web development circa 2001, when many people felt it was enough to put a big blob of PHP in a directory and let Apache serve it as one big app.
Nginx's fast reverse proxy allows developers to focus on building their apps, without having to worry too much the server details. It also offers a cleaner separation between concerns that should worry programmers and concerns that should worry the sysadmins.
(A final point: in my own apps, for information that needs to be shared quickly across apps, like which users are logged in, I use ZeroMQ to knit the apps together.)
- gnaritas 13y agoPeople have been and still do exactly the same thing with Apache, this isn't unique to Nginx in any way.
- jh3 13y agoHe did start his comment with "For my style of coding". Maybe it's just simpler to configure these rules in Nginx than it is in Apache for lkrubner.
- gnaritas 13y agoThe problem is that he says Nginx enabled fast reverse proxy and that's just not true, nothing he described was enabled by Nginx, that was how people already did things in Apache. Apache is not hard to configure, it would support his style of coding just fine and very likely work just as well as Nginx for him. The problem people have with Apache usually isn't really apache, it's with PHP forcing them to use the process based mpm which makes it a pig. This is PHP's fault, not Apache's. use the threaded or evened worker mpm's and it's not a pig at all.
- hardwaresofton 13y agoYes. It is remarkably simple to set up reverse proxies in nginx. It is also remarkably easy to set up SSL (minus generating certificates) -- it's only 3 lines.
- gnaritas 13y agoIt's just as easy in Apache.
- Helianthus 13y ago...No it isn't. It might be 'simple' for you, and it might be readily configurable once you know how to do it, but that doesn't make it easy. I really can't tell if you're being deliberately obtuse about this. Don't you see all the people going "Yeah, it was faster to do this with nginx than it was with Apache"? Are you the sort of person that's surprised PHP got so popular?
- acdha 13y agoI've been using Varnish for this: it's even simpler and has the advantage of having a non-broken HTTP cache module so you can use content negotiation and caching at the same time.
- cmbaus 13y agoThis is the reason we use nginx. It can hide the details of our multiple platform architecture. All the discussion around Nginx recently, has me wondering if I should revisit my own proxy project: http://switchflow.org/ http://switchflow.org/
- deleted 13y ago[deleted]
- Florin_Andrei 13y agoGreat summary.
- Nux 13y agoDude, what are you rambling about? The same can be achieved in Apache with 2 config lines. Nginx has taken over some of Apache's market because it's lighter on resources, i.e. with the same amount of resources it can process & deliver more stuff. Regarding functionality and configuration there is not much difference, actually I think Apache still has the edge here.
- oakaz 13y agoLet's consider boxcars also: http://github.com/azer/boxcars http://github.com/azer/boxcars
- rehack 13y ago>Nginx has taken over some of Apache's market because it's lighter on resources, i.e. with the same amount of resources it can process & deliver more stuff. That's precisely why we moved to Nginx. We do mostly Java so Apache was not the problem there, as it was simply proxying over to Jettys. But the blog is wordpress that means PHP, so we had to use modphp modules with Apache. That was Okay initially, but as we scaled, we saw some 50 instances of Apache and each taking 25 Mb memory. And note, most of the bloat in memory was due to modphp being loaded in-memory in each instance. We moved to Nginx with an external php-fpm for PHP, and just 4 Nginx instances take up the entire load and each uses some 2.5 Mb of memory. And at the same time Google webmaster shows a significant drop in average latency. So that's our experience of why we moved to Nginx. Edit: typo
- thwarted 13y agoSo you've moved the memory usage from the web server proper to the external php-fpm processes, which are most likely getting recycled more frequently than the default settings for apache prefork workers are so you're not seeing the ballooning PHP memory usage. The size of the 50 instances of Apache each taking 25 meg is most likely because of the PHP code and mod_php, not because of Apache itself.
- rehack 13y agoAgreed. In hindsight, I am sure, we could have externalized the PHP with Apache as well. But the larger context of this move was doing more with less. And Nginx just working with 4 instances and serving just as much, with a reduced average latency of page load, justified the move. And I sort of felt sad doing this. Because I have a huge respect for Apache. I hope just like what Chrome did to Firefox, Nginx does to Apache, and its a win-win for all.