nginx

The stub_status module provides the ability to get some stats from nginx...

active connections -- number of all open connections including connections to backends

server accepts handled requests -- nginx accepted connections, handled connections (no one was closed just it was accepted), and handles requests (requests per connection = handles requests / handled connections)

reading -- nginx reads request header

writing -- nginx reads request body, processes request, or writes response to a client

waiting -- keep-alive connections, actually it is (active - reading + writing)

The best way to think of things is that as a request comes in, Nginx will scan through the configuration to find a “location” line that matches the request. There are TWO modes that nginx uses to scan through the configuration file: literal string matching and regular expression checks. Nginx first scans through ALL literal string location entries in the order that they occur in the configuration file, and secondly scans through ALL the regular expression location entries in the order that they occur in the configuration file. So be aware – location ordering order DOES matter...

Nginx is a fast and efficient web server. It can be configured to serve out files or be a reverse proxy depending on your application. What makes this web server different from Apache, Lighttpd or thttpd is the overall efficiency of the daemon, the number of configuration options and how easy it is to setup....

Already happy with nginx in front of Apache for a number of sites, I decided it was time to start testing nginx/fastcgi on my personal server (the serial crash test dummy of my web operations). The only problem: I have yet to find a sensible method of grabbing useful runtime information from the PHP fastcgi process itself, and if you can’t sensibly watch it, you can’t sensibly deploy it.