Should Nginx Be Combined With Language Supporting Asynchronous Programming Model?

Question

I found there are a lot of articles comparing Nginx and Apache in Internet. However, all these comparisons are based on stress test to web server running PHP code. I suppose this is mainly due to Apache is generally deployed with PHP as LAMP architecture.

In my understanding, Nginx is created to solve C10K problem with event-based architecture. That is, Nginx is supposed to serve M concurrent requests with N threads/processes. N is supposed to much less than M. This is a big difference from Apache which needs M threads/processes to serve M concurrent requests.

For PHP code, the programming model is not asynchronous. Each web request would occupy one thread/process for PHP to handle it. So, I don't understand the meaning to compare Nginx and Apache with PHP code.

The event-based architecture of Nginx must excels Apache especially when requests involves I/O operations. For example, requests need to merge results from multiple other web services. For Apache+PHP, each requests might takes seconds just waiting for I/O operation complete. That would consume a lot of threads/processes. For Nginx, this is not a problem, if asynchronous programming is used.

Would it make more sense to deploy Nginx with language supporting asynchronous programming model?

I'm not sure which programming language could dig most potential from Nginx, but it id definitely not PHP.

Answer 1

The point is that potential doesn't matter. PHP is something of a standard for web development and so is what people usually care about with servers, so just because Ngnix or Apache are optimised to run an obscure programming language y times faster than the other is irrelevant unless it's PHP.

Answer 2

First and foremost, nginx does not support any application execution directly. It can serve static files, proxy requests to any other webserver and some other small things. Historically, nginx aimed to handle many network connections, true, but the rationale was this: until apache respond to the request of someone on slow connection, it can do nothing. Apache has a limit of workers, so when there are lots of slow clients, anyone new have to wait until a worker finishes the transfer and resumes accepting new request. So the classic setup is nginx accepting external requests, proxying them to the local apache; apache handles the requests and gives back the responses to the nginx to transfer to the clients. Thus apache is eliminated from dealing with clients.

Regarding the question and nginx in the picture. It's not that hard to utilize system event frameworks these days. That's epoll for Linux, kqueue for FreeBSD and others. At the application level lots of choices, twisted for python for example. So all you have to do is to write application with these frameworks, which 1) usually put you in async world and 2) give you a way to build HTTP service, ready to be backend for nginx. That's probably where you are aiming at.

So, c10k doesn't seem to be a problem for nginx, nor for applications built around these frameworks. Example at hand is friendfeed's tornado server: python written, uses epoll and kqueue depending on the system, handles up to 8k easyly, as i recall. There were some benchmarks and afterthought to scale it further.

Something must be brewing in ruby world about all the async trend, so they can come up with, if they haven't already. Ruby's passenger and mongrel, whatever in essense they are (i'm blanking on this), do work with nginx, and this required writing modules for nginx. So the community takes nginx into account and does extra when it needs to.

Php, by the way, stays relevant for pushes when websockets massively deployed. Oh well.