Does application server workers spawn threads?

Question

The application servers used by Ruby web applications that I know have the concept of worker processes. For example, Unicorn has this on the unicorn.rb configuration file, and for mongrel it is called servers, set usually on your mongrel_cluster.yml file.

My two questions about it:

1) Does every worker/server works as a web server and spam a processes/threads/fiber each time it receives a request, or it blocks when a new request is done if there is already other running?

2) Is this different from application server to application server? (Like unicorn, mongrel, thin, webrick...)

Answer 1

This is different from app server to app server.

Mongrel (at least as of a few years ago) would have several worker processes, and you would use something like Apache to load balance between the worker processes; each would listen on a different port. And each mongrel worker had its own queue of requests, so if it was busy when apache gave it a new request, the new request would go in the queue until that worker finished its request. Occasionally, we would see problems where a very long request (generating a report) would have other requests pile up behind it, even if other mongrel workers were much less busy.

Unicorn has a master process and just needs to listen on one port, or a unix socket, and uses only one request queue. That master process only assigns requests to worker processes as they become available, so the problem we had with Mongrel is much less of an issue. If one worker takes a really long time, it won't have requests backing up behind it specifically, it just won't be available to help with the master queue of requests until it finishes its report or whatever the big request is.

Webrick shouldn't even be considered, it's designed to run as just one worker in development, reloading everything all the time.

Answer 2

off the top of my head, so don't take this as "truth"

ruby (MRI) servers:

unicorn, passenger and mongrel all use 'workers' which are separate processes, all of these workers are started when you launch the master process and they persist until the master process exits. If you have 10 workers and they are all handling requests, then request 11 will be blocked waiting for one of them to complete.

webrick only runs a single process as far as I know, so request 2 would be blocked until request 1 finishes

thin: I believe it uses 'event I/O' to handle http, but is still a single process server

jruby servers:

trinidad, torquebox are multi-threaded and run on the JVM

see also puma: multi-threaded for use with jruby or rubinious

Answer 3

I think GitHub best explains unicorn in their (old, but valid) blog post https://github.com/blog/517-unicorn.

I think it puts backlog requests in a queue.