Contents 1 Problem Definition 1.1 Problems to solve 1.2 Constraints 1.3 Desired outcomes 2 Implementation 2.1 FastCGI docs 2.2 Details 2.3 Why it only works for PHP 2.4 Things to make it work for normal users 2.5 Todo

Problem Definition

Problems to solve

• PHP performance is really bad- it takes 0.3s to load the simple test pages we have
• Since php is run as a cgi every time, it cannot do opcode caching

Constraints

• Stuff must be run through our wrapper scripts
• We have finite resources on posiedon and can't exhaust them by leaving one or two processes open for every user

Desired outcomes

• Something that lets php keep running so it doesn't have to re-initialize every time

Implementation

FastCGI docs

• http://www.fastcgi.com/drupal
• http://www.fastcgi.com/drupal/node/25
• http://www.fastcgi.com/drupal/node/5?q=node/10

Details

• Works on a per-vhost level
• We want a dynamic application so that the fastcgi server can start/stop things as needed
• We will set up a FastCGIConfig for each virtual server
• Each virtual server will also have a FastCgiWrapper set up that points to the vhost wrapper script
• Each vhost will also need the apache User and Group directives set (these normally only apply to suEXEC, which we aren't running so their only effect is to tell FastCGI which user/group)
• Add-handler for /.wrapper/php-wrapper for fastcgi (this will replace the ScriptAlias line)
  • Otherwise fcgi will see each different php file as a separate application
  • This means we need to keep the RewriteCond rules for checking access
• php-cgi needs to be told to not run its own process manager so fcgi can start/stop it as necessary
  • Maybe we can have php-cgi start 2 or 3 threads?

Why it only works for PHP

• FastCGI doesn't seem to support having multiple different dynamic services
• The dyanmic service (through a wrapper) will start the php-cgi which runs as a fastcgi service.
• Since php-cgi will be running as the application (and it gets passed filename requests), it can't do normal cgi
• This isn't really a problem because normal cgi stuff will continue to work as normal cgi
• This solves our biggest problem anyways which is php initialization/parsing time

Things to make it work for normal users

• Set up a fcgi dynamic instance at ~username/.wrapper/php-wrapper
• Use a FastCGIWrapper that knows how to parse the uri for username
• Use mod_rewrite to rewrite requests for ~username/*.php to the user's own wrapper
• Need to add a check that the URI's going to the wrapper are for that user, otherwise you could run a different user's script under that user by calling the right url
  • This needs to be investigate and completely solved otherwise we make it lots worse by introducing a huge security hole in exchange for some performance

Todo

• Install it on dionysus
• Set up a test vhost
• Add User/Group to each vhost definition
• Modify the wrapper scripts
  • Still needs to be suid since we are using mod_fastcgi which runs under apache's uid/gid
  • Remove the pagsh since we will have k5start make a new one
  • Use user/group from command line instead of parsing the URL
  • Change uid before getting tokens
  • Set the environment for php-cgi so it does the right things with fcgi
  • Set it up so that we have k5start ... -t -- php-cgi