PHPFastCGI

280 rq/s to 1770 rq/s - Speed up Symfony, Silex and Slim with PHPFastCGI

Wed, 04 Nov 2015 01:00:00 +0000

The “What”

Let me start by clearing up a possible source of confusion for those of you familiar with FastCGI. This project is not about PHP-FPM. PHP-FPM is a great way of improving the performance of PHP applications, but the way it works is different to PHPFastCGI.

PHP-FPM keeps the PHP interpreter alive between HTTP request cycles.

PHPFastCGI keeps the PHP application alive between HTTP request cycles.

That’s all of your services, configuration… everything.

The “Why”

For a simple 500 page Symfony application, PHPFastCGI can take the performance from 280 rq/s to 1770 rq/s. If you’re interested, check the post on how the benchmarks were conducted. To summarize, I tried to make the Symfony application as fast as I could (OPCache enabled, PHP-FPM, NGINX). Then, I ran it as a PHPFastCGI application and compared the performance.

Please do not take those benchmarks too seriously (though I believe that they are significant). The top results were collected using a PHP extension that is currently lacking a few features (and not as stable as the default PHP implementation of the protocol). Also, a very helpful commenter has pointed out some ways that I could improve the benchmarks. As a result, I will be re-running them shortly.

Regardless, any application that has to reload itself on every HTTP request cycle will be significantly slower than a version of the same application that does not.

The “How”

Before doing this with an application, please read the post on things to consider when using PHPFastCGI with your application.

If your still think that your application is ready to be run in this way, it is really easy to create a FastCGI application using PHPFastCGI. With a Symfony application, you can do it by just installing a bundle.

The project also includes a Silex Adapter and a Slim Adapter. These provide wrappers for the core application classes of each framework.

You can also use the project without a framework, using the core FastCGIDaemon.

A framework-less PHPFastCGI application looks like this:

<?php // command.php

// Include the composer autoloader
require_once dirname(__FILE__) . '/../vendor/autoload.php';

use PHPFastCGI\FastCGIDaemon\ApplicationFactory;
use PHPFastCGI\FastCGIDaemon\Http\RequestInterface;
use Zend\Diactoros\Response\HtmlResponse;

// A simple kernel. This is the core of your application
$kernel = function (RequestInterface $request) {
    // $request->getServerRequest()         returns PSR-7 server request object
    // $request->getHttpFoundationRequest() returns HTTP foundation request object
    return new HtmlResponse('<h1>Hello, World!</h1>');
};

// Create your Symfony console application using the factory
$application = (new ApplicationFactory)->createApplication($kernel);

// Run the Symfony console application
$application->run();

References

If you have any suggestions or queries, please use the comment section below, GitHub or Twitter.

Also - as a cheeky request - if you like the sound of this project it would make me very happy if you shared it with your developer friends or gave it a star on GitHub.

PHPFastCGI Benchmarks - Symfony, Silex and Slim

Mon, 24 Aug 2015 00:25:00 +0000

Introduction

I have conducted a series of benchmark tests to illustrate the performance increases achievable when using the PHPFastCGI project. All of these tests have been conducted in good faith.

My purpose is not to advise you which is the best framework to use, or even to convince you that using PHPFastCGI in your application would be a good idea. For many PHP developers, the number of requests per second that their application can handle is not important. My purpose is only to prove that if you wish to develop high performance PHP applications, PHPFastCGI (and the technique it uses) can help.

Benchmarking System

Running inside VMWare Fusion: Ubuntu 64-bit Server 15.04, NGINX, PHP 5.6.4, 2GB RAM and 4 cores (Intel Core i7, 3.4 GHz).

For each of the frameworks, the application was initially benchmarked using the PHP FastCGI Process Manager (PHP-FPM) with the OPcache enabled.

For the PHPFastCGI benchmarks, a command line application was created for each of the frameworks using the appropriate adapter. Six instances of each application were then launched and NGINX’s inbuilt load balancer was used in round-robin mode. The benchmarks for the PHPFastCGI project were run twice, firstly using the PHP implementation of the FastCGI protocol and then using the php5-fastcgi extension.

Whilst PHP-FPM and PHPFastCGI sound similar, there is a very important difference:

PHP-FPM uses FastCGI to keep the PHP process alive between HTTP requests.
PHPFastCGI uses FastCGI to keep the PHP process and application alive between HTTP requests.

Because of this difference, applications using PHPFastCGI have to be developed very carefully. Read this article on things to consider when using PHPFastCGI with your application if you wish to know more.

The ‘ab’ benchmarking tool was used to conduct the tests. It was configured for 50000 requests at a concurrency level of 20.

The Tests

The first three tables show the benchmark results for simple ‘Hello, World!’ applications. The number of requests per second is a pretty useless figure here; what is more important is the reduction in the time taken to handle each request, as this indicates the amount of time shaved off the bootstrapping of the framework.

Symfony	Requests Per Second	Time Per Request (ms)
NGINX + PHP-FPM	551.59	1.813
NGINX + PHPFastCGI	1739.16	0.575
NGINX + PHPFastCGI (ext)	2469.36	0.405

Silex	Requests Per Second	Time Per Request (ms)
NGINX + PHP-FPM	1424.30	0.702
NGINX + PHPFastCGI	2332.22	0.429
NGINX + PHPFastCGI (ext)	4148.08	0.241

Slim (v3)	Requests Per Second	Time Per Request (ms)
NGINX + PHP-FPM	2058.91	0.486
NGINX + PHPFastCGI	2734.21	0.366
NGINX + PHPFastCGI (ext)	5562.47	0.180

In general, if the application is doing more there are greater potential time savings to be had. This is why the increase in performance of the micro-frameworks is less significant than that of the full stack Symfony framework. This is also why ‘Hello, World!’ benchmarks are actually the least impressive benchmarks for the PHPFastCGI project.

For a more realistic benchmark, I created a small 500 page website application using the Symfony framework. This has a single route configured that selects a random page from the database (MySQL) and renders it using Twig. The Doctrine entity repository is cleared after each request, so the framework is not caching the results of the queries. A much greater performance can be achieved by not doing this, but the purpose of this benchmark is to test when the application has actual work to do - so I have not cheated.

500 Page Website	Requests Per Second	Time Per Request (ms)
NGINX + PHP-FPM	282.55	3.539
NGINX + PHPFastCGI	1334.64	0.749
NGINX + PHPFastCGI (ext)	1769.94	0.565

Author Notes

Whilst I hope you agree that the result of these benchmarks is impressive, there is more work to be done! This project is still not stable, and I welcome any contributions that you may have. In particular, the php5-fastcgi extension would benefit from a review by someone with a knowledge of PHP internals.

Also, if you are attending ConFoo and would like to hear more about this project then please vote for my talk proposal.

References

Speedfony Bundle for Symfony
Silex Adapter
Slim Adapter
Speedfony Benchmarking App (500 page website)

You may also be interested in the core FastCGIDaemon Package, which can be used to create FastCGI applications without a framework (or with a different one).

The php5-fastcgi extension is still being developed and tested. Thus, there have been no releases of this software yet and the integration of this extension into the FastCGIDaemon core can only be found on the php5-fastcgi-ext branch of the repository.

This article was revised on 29th August 2015 to contain more accurate benchmarks. Changes include turning on the opcache and significant changes to the FastCGIDaemon core.

This article was revised again on 9th September 2015 to include benchmarks using the php5-fastcgi extension currently under development.

Things to consider when developing an application with PHPFastCGI

Fri, 21 Aug 2015 09:00:00 +0000

Introduction

Let me start with something very important.

Not every application is a suitable candidate to become a FastCGI application.

In conventional PHP applications, HTTP requests are nicely separated from each other. Web servers handle each HTTP request as a different execution of an application. This provides a degree of safety and security. If you choose to run your PHP application as a FastCGI application, you forefit this for an increase in performance.

Fatal Errors and Exceptions

A properly written application should not respond to clients with uncaught errors and exceptions. The consequences, however, of doing this in a FastCGI application are much steeper.

A fatal error will cause your application to terminate and stop listening for requests. Something will need to restart your application otherwise it will stay down.

The best practice is to make sure that all errors and exceptions are appropriately caught and logged without terminating the application. You should also make sure that your application is being managed by a suitable process manager so that if it does crash, it will be promptly restarted.

Apache’s mod_fastcgi includes a process manager that is very easy to configure. If you are using a web server such as NGINX, you may need to use a process manager such as supervisord.

Code Updates and Deployment

Usually when we make changes to our application, these are recognised immediately as PHP rereads our file every time it executes it. In some scenarios, we may have to flush caches but that is about as tricky as it usually gets. When working with long running processes, we have to make sure that we shutdown and reload our application when we update its code.

This can be an easy step to forget! Many times I have found myself staring blankly at error messages before remembering that I needed to reload the application whilst developing this very project!

I am currently working on features to ensure that shutdown signals cause PHPFastCGI applications to exit cleanly after they have finished handling and responding to all open requests.

When running multiple instances of your FastCGI application, you should desire a configuration that allows you to shutdown and restart instances individually to prevent down time. Running multiple instances of your application is also recommended for performance reasons.

If you are using apache’s mod_fastcgi to process manage your application, a graceful reload of the web server may be your best option.

Memory Segregation

Static memory and global variables are well documented enemies. If you intend to create a FastCGI application, you should avoid these like the plague (that includes $_SESSION, $_POST, $_GET, etc…).

Any scenario where a HTTP request could influence, interfere or read memory that is shared by a later (or earlier) HTTP request is an opportunity for an attacker.

Memory Leaks

Although this is changing, PHP applications and frameworks are not usually designed to run for long periods of time. Anyone who has ever worked with a low level language (such as C or C++) will understand that the traditional PHP developer approach to memory allocation is incredibly lacking in any form of principal or organization.

This is an approach that we cannot afford to take when developing long running applications. PHP itself is now very good at cleaning up memory automatically once it is no longer required. Nowadays, most memory leaks in our PHP applications can be traced to dangling references either inside the application or within its dependencies.

For example, Doctrine’s SQL logger (enabled by default in the Symfony development environment) can very quickly cause a resource issue. If you are using the Doctrine Entity Manager, you must also take care to use the EntityManager::clear() method provided and remove references to entities that you no longer require it to manage.

One potential approach for handling memory leaks is to restart application instances after they have been operating for a certain amount of time or handled a certain number of requests. This feature is scheduled for integration into the FastCGIDaemon core package and will be available before the first stable release. However, it is still considered best practice to try and develop applications without memory leaks.

Connection Timeouts

One of the advantages of using PHPFastCGI to keep your application alive is not having to reconnect to databases, cache layers and message queues for every HTTP request. However, should any of these connections timeout or otherwise disconnect, your application must contain logic to restablish these. Failure to do so will leave you with 5XX error codes and possibly useless instances of your application running.

This is a particularly nasty bug, as you may not notice it until you have deployed to your production server and gone though a quiet patch in the early hours of the morning.

Conclusion

There is lots to be gained and lots to be lost by daemonizing your PHP applications. It is very important that you are aware of the potential issues you could face and how to mitigate these. However, with a properly designed and carefully considered application - you can reach response speeds well beyond the dreaming limits of conventional PHP applications.

How to make Symfony faster

Tue, 14 Jul 2015 10:00:00 +0000

By turning your Symfony application into a FastCGI application, you can keep the application in memory between request cycles.

Before doing this, please read the post on things to consider when using PHPFastCGI with your application.

To do this, open the terminal in your project directory and run the following command:

php composer.phar require "phpfastcgi/speedfony-bundle"

This command adds the Speedfony Bundle to your composer dependencies.

Now you need to register the bundle in your AppKernel.php file:

// app/AppKernel.php

// ...
class AppKernel extends Kernel
{
  public function registerBundles()
  {
    $bundles = array(
      // ...
      new PHPFastCGI\SpeedfonyBundle\PHPFastCGISpeedfonyBundle(),
    );

    // ...
  }
// ...

Your application can now be run as a FastCGI application listening on FCGI_LISTENSOCK_FILENO (stdin) using this command:

php app/console speedfony:run --env="prod"

You can also configure the FastCGI application to listen on a TCP address using the ‘port’ and ‘host’ options:

php app/console speedfony:run --env="prod" --port 5000

Welcome to PHPFastCGI

Mon, 13 Jul 2015 19:24:12 +0000

Welcome to the website for the PHPFastCGI project. I’m going to use this space to post updates on the project, document features and show examples - all with the aim of making the software easier to use.

Please watch this space if you find this project interesting.