As you have already noticed, Ratchet applications are not deployed like your typical PHP application, but in fact run their own HTTP server that can directly answer HTTP requests. Also, most applications will not only serve WebSocket connections, but also need to process regular HTTP requests, too.

This will open an entire set of new problems to solve. One of them is scalability: by default, PHP runs single-threaded, so even when using the asynchronous event loop offered by libev, your application will never scale beyond a single CPU. While you could consider using the pthreads extension to enable threading in PHP (and to enter a whole new world of pain), it is usually easier to simply start the Ratchet application multiple times, have it listen on different ports, and use a load-balancer such as Nginx to distribute HTTP requests and WebSocket connections among them.

For processing regular (non-WebSocket) HTTP requests, you can still use a regular PHP process manager such as PHP-FPM or Apache's PHP module. You can then configure Nginx to dispatch those regular requests to FPM and all WebSocket requests to one of your running Ratchet applications.

Deploying and load-balancing Ratchet applications using an Nginx load balancer

To achieve this, you first need to make the port that your application listens on so that it can be configured separately for each running process. As the application is started through the command line, the easiest way to make the port configurable per-process is a command-line parameter. You can use the getopt function to easily parse command-line parameters. While you're at it, you can also make the listen address configurable. Insert the following code into your server.php file:

$options = getopt('l:p:', ['listen:', 'port:']);

$port = $options['port'] ?? $options['p'] ?? 8080;

$addr = $options['listen'] ?? $options['l'] ?? '127.0.0.1'; 
 
$app = new RatchetApp('localhost', $port, $addr); 
$app->route('/chat', new PacktChp6ChatChatComponent); 
$app->run(); 

Next, you need to make sure your server actually automatically starts a sufficient number of processes. In a Linux environment, the Supervisor tool is usually a good choice for this. On Ubuntu or Debian Linux systems, you can install it from the system's package repositories using the following command:

$ apt-get install supervisor

You can then place a configuration file in /etc/supervisor/conf.d/ with the following contents:

[program:chat] 
numprocs=4 
command=php /path/to/application -port=80%(process_num)02d 
process_name=%(program_name)s-%(process_num)02d 
autostart=true 
autorestart=unexpected 

This will configure Supervisor to start four instances of the chat application on system boot. They will listen at the ports 8000 to 8003 and will automatically be restarted by Supervisor when they unexpectedly terminate-remember: a PHP fatal error may be relatively harmless in a FPM-managed environment, but in a standalone PHP process, a single fatal error will bring down your entire application for all users until someone restarts the process. For this reason, it's good to have a service like Supervisor that automatically restarts crashed processes.

Next, install an Nginx web server to serve as a load balancer for the four running chat applications. On Ubuntu or Debian, install Nginx as follows:

$ apt-get install nginx

After having installed Nginx, place a configuration file chat.conf in the directory /etc/nginx/sites-enabled/ with the following contents:

upstream chat { 
    server localhost:8000; 
    server localhost:8001; 
    server localhost:8002; 
    server localhost:8003; 
} 
server { 
    listen 80; 
    server_name chat.example.com; 
 
    location /chat/ { 
        proxy_pass http://chat; 
        proxy_http_version 1.1; 
        proxy_set_header Upgrade $http_upgrade; 
        proxy_set_header Connection "upgrade"; 
    } 
 
    // Additional PHP-FPM configuration here 
    // ... 
} 

This configuration will configure all four application processes as upstream servers for the Nginx load balancer. All HTTP requests starting with the /chat/ path will be forwarded to one of the Ratchet applications running on the server. The proxy_http_version and proxy_set_header directives are necessary to allow Nginx to correctly forward the WebSocket handshake between server and client.