Bloggitation

Preparation

I added PHP to bbox512 nginx . For Debian/Ubuntu it needed FastCGI:

# apt-get install libfcgi0

RTFM

• Init-script for php-cgi in external FASTCGI Mode
• Nginx, PHP and a PHP FastCGI daemon init script
• bye Redskin, zdravstvujte Redstar

Installation

# cd /etc/default/
# wget -O php-fastcgi http://zhware.net/files/nginx/php-fastcgi.txt
# cd /etc/init.d/
# wget -O php-fastcgi http://zhware.net/files/nginx/php-fastcgi.rc.txt
# chmod 755 php-fastcgi
# cd /opt/nginx/conf/sites/
# wget -O static.conf http://zhware.net/files/nginx/sites/static.conf.txt
# /etc/init.d/php-fastcgi start
# kill -HUP `cat /opt/nginx/logs/nginx.pid`

In fact it’s just starting FastCGI PHP instances and making small changes to the sites/static.conf to process files with .php extension:

location ~ \.php$ {
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_index index.php;
  fastcgi_param SCRIPT_FILENAME /opt/nginx/html$fastcgi_script_name;
  fastcgi_param QUERY_STRING $query_string;
  fastcgi_param REQUEST_METHOD $request_method;
  fastcgi_param CONTENT_TYPE $content_type;
  fastcgi_param CONTENT_LENGTH $content_length;
}

FastCGI is difficult to install/manage. Really it is :(

Problem: DHH loves FastCGI. There is so many FastCGI-centric stuff in Rails:

• script/process/ scripts
• the default lighttpd.conf, generated by script/server

Solution: Zed Shaw

First Zed gave as SCGI_Rails – pure ruby, working on *nix (Linux, BSD, OS X) and Windows. Today I found also another way to skip fastcgi pain with Zed’s stuff – Mongrel :

• Using Lighttpd with Mongrel – have interesting tips for using mod_cml (Lua) for cache management
• Playing with Lighttpd, Litespeed, FCGI and Mongrel – some Lighttpd+Mongrel combi benchmarks

And by the way I wrote some notes about the Second Osaka Rails Meeting (Using runit) on the wiki. FastCGI, SCGI, Mongrel notes included.

Found via Rails Tips , link point to TextDrive weblog

• Minimize the amount of FCGI listeners
• Use caching
• NEVER run “development” on FastCGI for more than 1-2 hours
• Observe your memory consumption
• Rotate your logs
• Write and run unit tests
• Check for memory leaks when you are developing
• Be careful with iterations
• Watch the Rails TRAC for bug reports
• Be vigilant when restarting your server

Use RailsHelp for quick searching through the Rails API docs.

Great tip from the Feedmarker blog :

Change the following line in your dispatch.cgi (or dispatch.fcgi, depending on which you use) file:

RailsFCGIHandler.process!

to

RailsFCGIHandler.process! nil, 1

This tells Rails to run the garbage collector and restart your app after each request (if you put the number 2 in there, there’ll be two requests, etc.). Then load your site. Now you can go back into your dispatcher file and change the setting back to normal.

An example config:

<IfModule mod_fastcgi.c>
  FastCgiIpcDir /tmp/fcgi_ipc
  FastCgiServer /path/to/myapp/dispatch.fcgi \
    -initial_env RAILS_ENV=production \
    -processes 15 -idle-timeout 60
</IfModule>

The important part is FastCgiServer . It creating static server definition – 15 fastcgi servers are started right after the server is launched and running until the server is stopped. That whay is faster that to relay on Apache to start the servers when the first time .fcgi page is accessed (dynamic server definition).

idle-timeout also is critical value. If any request takes longer than the limit, Apache will assume the FastCGI process crashed and return an error 500. If the application talks to remote servers (process requests slower) increase the idle-timeout from the default 30 to 60 seconds.