php-pm

PPM is a process manager, supercharger and load balancer for modern PHP applications.

6,555

370

6,555

View on GitHub

Top Related Projects

http-server

1,321

An advanced async HTTP server library for PHP, perfect for real-time apps and APIs with high concurrency demands.

roadrunner

8,373

🤯 High-performance PHP application server, process manager written in Go and powered with plugins

swoole-src

18,864

🚀 Coroutine-based concurrency library for PHP

Quick Overview

PHP-PM (PPM) is a process manager, supercharger, and load balancer for PHP applications. It aims to boost performance by maintaining a pool of ready-to-use PHP workers, eliminating the need to bootstrap the application for each request. PPM is designed to work with various PHP frameworks and applications.

Pros

Significantly improves PHP application performance by reducing bootstrap overhead
Supports multiple popular PHP frameworks out of the box (Symfony, Laravel, Zend Framework)
Provides built-in load balancing and process management
Offers easy integration with existing PHP applications

Cons

Requires additional setup and configuration compared to traditional PHP deployments
May not be suitable for all types of PHP applications, especially those with specific runtime requirements
Limited support for some PHP extensions and features that rely on per-request initialization
Potential learning curve for developers unfamiliar with process management concepts

Code Examples

Starting PPM with a Symfony application:

<?php
use PHPPM\Bridges\Symfony;

$bridge = new Symfony();
$bridge->bootstrap();
$app = $bridge->getApplication();

// Your Symfony application is now bootstrapped and ready to handle requests

Configuring PPM for a Laravel application:

<?php
return [
    'bridge' => PHPPM\Bridges\Laravel::class,
    'host' => '127.0.0.1',
    'port' => 8080,
    'workers' => 8,
    'app-env' => 'production',
    'debug' => false,
    'logging' => false,
    'static-directory' => 'public/',
];

Handling a request in a custom PPM bridge:

<?php
namespace PHPPM\Bridges;

use PHPPM\Bridges\HttpKernel;

class CustomBridge extends HttpKernel
{
    public function handle(ServerRequestInterface $request): ResponseInterface
    {
        // Custom request handling logic
        $response = $this->application->handle($request);
        return $response;
    }
}

Getting Started

Install PHP-PM using Composer:
```
composer require php-pm/php-pm
```

Create a PPM configuration file (ppm.json):

{
  "bridge": "PHPPM\\Bridges\\Symfony",
  "host": "127.0.0.1",
  "port": 8080,
  "workers": 8,
  "app-env": "prod",
  "debug": false
}

Start PPM:

./vendor/bin/ppm start --config=ppm.json

Your PHP application is now running with PHP-PM, ready to handle requests with improved performance.

Competitor Comparisons

http-server

1,321

An advanced async HTTP server library for PHP, perfect for real-time apps and APIs with high concurrency demands.

Pros of http-server

Built on the amphp ecosystem, providing seamless integration with other amphp components
Designed for high concurrency and non-blocking I/O, potentially offering better performance in certain scenarios
More actively maintained with regular updates and contributions

Cons of http-server

Steeper learning curve due to its asynchronous nature and unique programming model
Less widespread adoption compared to php-pm, potentially resulting in a smaller community and fewer resources

Code Comparison

http-server:

$server = new Server($logger, $socket);
$server->expose($socket);
$server->start();

php-pm:

$loop = Factory::create();
$app = new Application($loop);
$app->run('0.0.0.0:8080');

Both projects aim to improve PHP's performance in serving HTTP requests, but they take different approaches. http-server focuses on leveraging asynchronous programming patterns, while php-pm emphasizes process management and worker pooling. The choice between them depends on specific project requirements, familiarity with asynchronous programming, and the desired level of integration with other components in the respective ecosystems.

roadrunner

8,373

🤯 High-performance PHP application server, process manager written in Go and powered with plugins

Pros of RoadRunner

Written in Go, offering better performance and lower memory usage
Supports multiple PHP versions and frameworks out of the box
Includes built-in load balancing and service discovery features

Cons of RoadRunner

More complex setup and configuration compared to PHP-PM
Requires additional system dependencies (Go runtime)
May have a steeper learning curve for PHP developers unfamiliar with Go

Code Comparison

RoadRunner configuration (.rr.yaml):

http:
  address: 0.0.0.0:8080
  workers:
    command: "php worker.php"
    pool:
      numWorkers: 4

PHP-PM configuration:

$loop = \React\EventLoop\Factory::create();
$socket = new \React\Socket\Server('0.0.0.0:8080', $loop);
$server = new \PHPPM\ProcessManager\ProcessManager($loop, $socket);
$server->setProcessCount(4);
$server->run();

Both projects aim to improve PHP application performance by managing worker processes. RoadRunner offers a more feature-rich solution with better performance, while PHP-PM provides a simpler, pure PHP implementation. The choice between them depends on project requirements, team expertise, and infrastructure constraints.

swoole-src

18,864

🚀 Coroutine-based concurrency library for PHP

Pros of swoole-src

Written in C, offering better performance and lower resource usage
Provides a more comprehensive set of features, including WebSocket, TCP/UDP server, and async I/O operations
Integrates seamlessly with PHP as an extension, allowing for easier adoption in existing projects

Cons of swoole-src

Requires compilation and installation as a PHP extension, which can be more complex than php-pm
May have compatibility issues with some PHP libraries and frameworks not designed for asynchronous execution

Code Comparison

swoole-src:

$server = new Swoole\HTTP\Server('127.0.0.1', 9501);
$server->on('request', function ($request, $response) {
    $response->end('<h1>Hello World</h1>');
});
$server->start();

php-pm:

$app = new Symfony\Component\HttpFoundation\Request();
$app->get('/', function () {
    return new Response('<h1>Hello World</h1>');
});

Summary

swoole-src offers superior performance and a wider range of features, making it suitable for high-performance applications. However, it requires more setup and may have compatibility issues. php-pm is easier to integrate but may not provide the same level of performance or feature set. The choice between the two depends on project requirements and the development team's expertise.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

PPM - PHP Process Manager

PHP-PM is a process manager, supercharger and load balancer for PHP applications.

It's based on ReactPHP and works best with applications that use request-response frameworks like Symfony's HTTPKernel. The approach of this is to kill the expensive bootstrap of PHP (declaring symbols, loading/parsing files) and the bootstrap of feature-rich frameworks. See Performance section for a quick hint. PHP-PM basically spawns several PHP instances as worker bootstraping your application (eg. the whole Symfony Kernel) and hold it in the memory to be prepared for every incoming request: This is why PHP-PM makes your application so fast.

More information can be found in the article: Bring High Performance Into Your PHP App (with ReactPHP)

Features

Performance boost up to 15x (compared to PHP-FPM, Symfony applications).
Integrated load balancer.
Hot-Code reload (when PHP files change).
Static file serving for easy development procedures.
Support for HttpKernel (Symfony/Laravel), Drupal (experimental), Zend (experimental).

Badge all the things

Does your app/library support PPM? Show it!

[![PPM Compatible](https://raw.githubusercontent.com/php-pm/ppm-badge/master/ppm-badge.png)](https://github.com/php-pm/php-pm)

Use

cd into/your-application

# run Symfony
docker run -v "$(pwd):/var/www" -p 8080:80 phppm/nginx --bootstrap=symfony --static-directory=web/

# run Laravel
docker run -v "$(pwd):/var/www" -p 8080:80 phppm/nginx --bootstrap=laravel --static-directory=public/

Docker is easier to setup and maintain. If your applications requires additional environment tools or libraries, you can build your own image based on ours. See github.com/php-pm/php-pm-docker for more information.

When debug is enabled, PHP-PM detects file changes and restarts its worker automatically.

Use without Docker

Follow the wiki article Use without Docker.

Performance

To get the maximum performance you should usually use --app-env=prod with disabled debug --debug=0. Also make sure xdebug is disabled. Try with different amount of workers. Usually a 10% over your cpu core count is good. Example: If you have 8 real cores (excl. hyper-threading) use --workers=9.

To get even more performance (for static file serving or for rather fast applications) try a different event loop (see https://github.com/reactphp/event-loop).

Debugging

If you get strange issues in your application and you have no idea where they are coming from try using only one worker --workers=1 and enable -v or -vv.

When debugging you should use xdebug as you're used to. If you set a break point and hold the application, then only one worker is stopped until you release the break point. All other workers are fully functional.

Note for XDebug and PHPStorm: Since php-pm uses at least two processes, there are two xdebug instances as well. PHPStorm is per default configured to only accept one connection at a time. You need to increase that. You won't get xdebug working with your application if you don't increase that count.

Xdebug and PHPStorm

In all workers the STDOUT is redirected to the connected client. So take care, var_dump, echo are not displayed on the console. STDERR is not redirected to the client, but to the console. So, for very simple debugging you could use error_log('hi') and you'll see it on the console. Per default exceptions and errors are only displayed on the console, prettified with Symfony/Debug component.

Adapter

HttpKernel for Symfony/Laravel - https://github.com/php-pm/php-pm-httpkernel

Zend - https://github.com/php-pm/php-pm-zend

CakePHP - https://github.com/CakeDC/cakephp-phppm

Command

ppm-help

ppm-start

Symfony

cd my-project
docker run -v `pwd`:/var/www -p 8080:80 phppm/nginx --static-directory=web/

Laravel

cd my-project
docker run -v `pwd`:/var/www -p 8080:80 phppm/nginx --bootstrap=laravel --static-directory=web/

Zend

cd my-project
docker run -v `pwd`:/var/www -p 8080:80 phppm/nginx --bootstrap=Zf2

Wordpress

For all Wordpress lovers out there: PPM is not going to work with Wordpress due to the lack of request-response abstraction. We highly doubt that Wordpress is ever going to be compatible because its architecture is written in a way that makes it currently impossible to serve multiple requests in one application process.

Performance (requests/s)

6x4GHz Intel i7, 16GB RAM. 10 concurrent, 1000 total request: ab -c 10 -n 1000 http://127.0.0.1:8080/

Symfony, CMS application

ppm start --bootstrap=symfony --app-env=prod --logging=0 --debug=0 --workers=20

https://github.com/jarves/jarves

PHP Version	Dynamic at Jarves	Static file
7.0.3, StreamSelectLoop	2387,67	3944,52
5.6.18, StreamSelectLoop	1663,56	2636,09
5.6.18, LibEventLoop	1811,76	3441,72

Laravel, example package

https://github.com/bestmomo/laravel5-example

ppm start --bootstrap=laravel --app-env=prod --debug=0 --logging=0 --workers=20

Issues

Memory leaks, memory leaks and memory leaks. You will also find leaks in your application. :) But no big issue since workers restart automatically.
Does not work with ExtEventLoop. (So don't install php70-event, but you can try LibEventLoop php56-libevent)
Drupal and Zend is very experimental and not fully working. Try using https://github.com/php-pm/php-pm-drupal.
Laravel's debugger isn't working perfectly yet since it's still needed to reset some stuff after each request.
Streamed responses are not streamed yet
No windows support due to signal handling

Please help us fix these issues by creating pull requests. :)

Setup

We provide ready-to-use docker images you can use right away. If you have own setup, see in the PHP-PM docker repository how to integrate PHP-PM in your NGiNX setup.

Trusted proxy Symfony

To get the real remote IP in your Symfony application for example, don't forget to add ppm (default 127.0.0.1) as trusted reverse proxy.

# app/config/config.yml
# ...
framework:
    trusted_proxies:  [127.0.0.1]

More information at http://symfony.com/doc/current/cookbook/request/load_balancer_reverse_proxy.html.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot