Watched the below post on architecture over at Meebo
Got me thinking about:
Pre Forking with aynchronous servers
In general I was interested in the issue of running asynchronous servers on multiple processors/cores.
Seems that this can be done in multiple servers:
Facebook Tornado Python server
Meebo talk on asynchronous architecture
Apache CGI process per request - memory efficiency sucks!
Gevent + Gunicorn
Gevent + Gunicorn
For SSL support, both Gunicorn and Tornado recommend you run them behind a reverse proxy such as nginx.
Gunicorn - Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. It's a pre-fork worker model ported from Ruby's Unicorn project.
Greins - Greins is a Gunicorn application which makes it easy to configure and manage any number of WSGI apps in one server daemon.
Ways to run Tornado
1. listen: simple single-process:
2. bind/start: simple multi-process:
3. add_sockets: advanced multi-process:
The "pre-forking" phrase is used to mean a couple of different things, so it is worth clarifying what it means for Tornado. Essentially, we bind a single server socket to a port, and we fork() one process per CPU. Each of those CPUs calls accept() on the shared server socket, and the Linux kernel gives new requests to one of the child processes on a first-come-first-serve basis. Each of the child processes has their own epoll-based IO loop, and a single request is handled entirely within one of the child processes. There is no shared memory or shared state between the forked child processes, only a shared port.
In the classic setup you have nginx sending requests to a pool of mongrels using a smart balancer or a simple round robin. Eventually you want better visibility and reliability out of your load balancing situation, so you throw haproxy into the mix:
Http Proxy Load Balancer Cluster of web servers
Nginx -> Haproxy -> (Mongrel or Unicorn or …)
Unicorn is a traditional UNIX prefork web server. No threads are used at all, this makes applications easier to debug and fix. When your application goes awry, a BOFH can just “kill -9” the runaway worker process without worrying about tearing all clients down, just one. Only UNIX-like systems supporting fork() and file descriptor inheritance are supported.
While reading up on these topics I found out about WSGI which is the equivalent of Ruby's Rack as far as I can tell.
Quick note on how nginx fits in.
Varnish is an HTTP accelerator designed for content-heavy dynamic web sites. In contrast to other HTTP accelerators, such as Squid, which began life as a client-side cache, or Apache and nginx, which are BOLDprimarily origin serversBOLD, Varnish was designed as an HTTP accelerator. Varnish is focused exclusively on HTTP, unlike other proxy servers that often support FTP, SMTP and other network protocols.