Application Server
With the other pieces in place, we now need the biggest piece of the puzzle: the
application server that handles all of the dynamic requests. Right now, the best solution
is Mongrel.??
Prior to Mongrel, Rails applications were best served using the CGI protocol or some
variation thereof (FastCGI or SCGI). The basic idea behind this is that the front end
web server would talk to the application server using a special protocol, with one
connection per request (see Figure 10-8). CGI has the limitation that one new process
is created for each request, which is extremely slow for interpreted languages
such as Ruby. Therefore, the FastCGI and SCGI protocols were created. They have
the advantage that they can work with persistent interpreters??”one interpreter can
serve many requests over the lifetime of the process. This solution can be scaled by
adding more workers.
However, the front end server is still a limiting factor here. The front end server handles
every request from start to finish, something we can actually eliminate with a
load-balanced setup. In addition, using two different protocols confuses things: the
application servers speak FastCGI, and the web servers speak HTTP. To top it off,
Apache??™s mod_fastcgi has had a reputation for crashing after being up for a while.
* See http://www.die.net/musings/page_load_time/ for a full explanation.
Pages:
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486