Do you support FastCGI?
Our servers support the FastCGI protocol to speed up scripts for busy sites. FastCGI provides a way to keep frequently-run script files loaded in memory so that the script is already preloaded and initialized the next time it's used.
This can make some scripts (particularly PHP scripts) run much more quickly. For example, a simple "Hello World" PHP script can run more than 400 times a second using FastCGI (compared to 5 times per second without). In most cases, using FastCGI for PHP scripts is as fast as using mod_php, without the security drawbacks.
Keep in mind that using FastCGI adds a little bit of complexity to the way your scripts are run, and isn't usually worth it for sites that have fewer than 2000 script "hits" a day.
The information below explains how to use FastCGI to improve script performance on your site.
- Using FastCGI for PHP
- Why isn't FastCGI always enabled for PHP scripts?
- Some technical notes about PHP and FastCGI
- PHP, FastCGI, and eAccelerator
- Using FastCGI with Ruby on Rails
- Using custom FastCGI programs
- Which FastCGI module is installed?
- Why isn't FastCGI easier to set up?
Using FastCGI for PHP
You can use FastCGI to run PHP scripts more quickly (in fact, this is probably the most common use). To run PHP scripts via FastCGI, you need to install a "wrapper" program and add two lines to the .htaccess file at the top level of your site.
Tiger Technologies can set this up for you if necessary, so if you don't understand the instructions below, just contact us and we'll take care of it.
The wrapper script must be placed at the top level of the Web site and must be named "php-fastcgi.fcgi" (this special name is exempt from subdomain rewriting and therefore works properly in an "Action" handler for a subdomain). It must also be mode 0755 (from the command line, you'd type "chmod 0755 php-fastcgi.fcgi").
The contents of the file should be these lines:
#!/bin/sh exec /usr/bin/php5-cgi -c /etc/php5/cgi/php-fcgi.ini
After creating that file, the following two lines must be added to the site's top-level .htaccess file:
AddHandler php-fastcgi .php Action php-fastcgi /php-fastcgi.fcgi
That overrides the normal handling of PHP files, running them via the "wrapper", which in turn is run by FastCGI because it has a name ending in .fcgi.
If you're uploading these two files using an FTP program, make sure your program uses text (or "ASCII") mode, not binary mode. Most FTP programs will choose text mode automatically. If you see "internal server errors", your FTP program probably uploaded the "php-fastcgi.fcgi" file in binary mode by accident.
If you want to use FastCGI for most of your PHP scripts, but you also have one or more individual directories containing scripts that need to be run without FastCGI, you can disable FastCGI for an entire directory. To do that, add this line to a .htaccess file in the directory:
AddHandler application/x-httpd-php .php
This tells Apache to run PHP scripts in that directory using the normal method, no matter what higher-level .htaccess files contain.
Why isn't FastCGI always enabled for PHP scripts?
The only reason it isn't enabled for all sites is that a small handful of very old PHP scripts don't work properly with FastCGI. However, we've only seen this potential problem with very old scripts (older than five years or so). Although it's always wise to review your site after any change, you shouldn't notice any difference other than your scripts running more quickly.
Some technical notes about PHP and FastCGI
One good thing about PHP and FastCGI is that you can easily disable it yourself if you suspect it's causing a problem. To set PHP files back to normal operation, simply remove the AddHandler line from the .htaccess file,and FastCGI will no longer be used. (Note that you can't simply delete the wrapper script: in fact, deleting the wrapper script will cause a "file not found" error to occur if the AddHandler line is still present in the .htaccess file. Similarly, if the wrapper script is not set to mode 0755, or if it includes DOS carriage returns instead of plain Unix linefeed characters, you will see an "internal server error".)
Another thing to keep in mind is that if you change your php.ini settings as described on our PHP page, the change won't take effect until FastCGI decides to re-launch your script, which can take up to 30 minutes. You may wish to disable FastCGI handling of PHP scripts for 30 minutes if you make a php.ini settings change.
PHP, FastCGI, and eAccelerator
We use the eAccelerator PHP accelerator to further speed up PHP scripts that are run under FastCGI. (We don't currently use eAccelerator for non-FastCGI PHP scripts.)
If you encounter any problems as a result of eAccelerator, one simple solution is to disable FastCGI for PHP, as described above. Alternately, you can disable eAccelerator and leave FastCGI turned on by putting this line in your custom php.ini file:
eaccelerator.enable = 0
Doing so costs you about half the speed advantage of using FastCGI to handle PHP scripts, though.
One other possibility is to fix the PHP script that causes the error. In particular, if you see "Cannot redeclare (something)" errors, changing "require" and "include" lines to "require_once" or "include_once" in the PHP scripts will usually solve it.
Using FastCGI with Ruby on Rails
See our Ruby page to learn how to use FastCGI with Ruby on Rails.
Using custom FastCGI programs
To use a custom FastCGI program, install it like any other compiled script, but make sure that the name ends with ".fcgi" instead of the normal ".cgi".
For example, you might install a FastCGI program named "program.fcgi" in your cgi-bin folder, and it would then be accessible as:
http://www.example.com/cgi-bin/program.fcgi
Alternately, you can force a ".cgi" file to be run under FastCGI with this .htaccess file line:
AddHandler fastcgi-script .cgi
(This only works if the CGI script has been coded to support FastCGI, of course. For example, it works with Movable Type 3.34 and later, speeding up the Movable Type interface substantially.)
Which FastCGI module is installed?
We use mod_fcgid with some custom modifications. We've found mod_fcgid to be superior to the alternative mod_fastcgi — in particular, mod_fcgid works properly with dynamically launched PHP scripts, but mod_fastcgi does not. Also, mod_fcgid is the module recommended in the Ruby on Rails documentation.
In practice, users should notice no difference between the two modules. Properly written FastCGI applications will work with either mod_fastcgi or mod_fcgid.
Why isn't FastCGI easier to set up?
We know that it's annoying to have to modify two files to make FastCGI work for PHP scripts. We apologize for that: We're actively working on making this a "checkbox" interface within our control panel.
