Nginx Unit beats the legacy stacks

Nginx Unit outperforms traditional stacks by a significant margin. Apache mod_php consumes about 100 MB of RAM when running 25 threads, whereas Nginx maintains a footprint of only 10 MB. At 1000 concurrent connections, Nginx+PHP-FPM serves approximately twice as many requests as Apache-based stacks. Apache relies on a process or thread per connection, which forces the kernel to perform context switching as the load climbs. Nginx uses an event-driven, asynchronous architecture to keep memory usage flat. I skip Apache when I need to handle high concurrency or mitigate Slowloris attacks. This type of attack keeps an Apache thread occupied by opening a connection and never finishing the request. For small deployments, the speed difference between Nginx and Apache matters less, but for high-traffic sites, the event-driven model wins. Apache provides the benefit of .htaccess for per-directory configuration, but Nginx serves static files much faster.

In a self-hosted setup, Nginx remains the common choice to terminate HTTPS and route by hostname to various services.

The performance gap in PHP runtimes

Nginx Unit handles requests significantly faster than the standard Nginx+PHP-FPM setup. Benchmarks performed on an AWS EC2 t2.micro instance show Nginx Unit performs roughly 3 times faster than Nginx+PHP-FPM. Roadrunner-based stacks also beat Nginx+PHP-FPM by more than 2 times. While FrankenPHP in worker mode hits speeds over 10 times faster than Nginx+PHP-FPM, Nginx Unit provides a lightweight alternative for dynamic environments. Since you already know that PHP runtimes like Swoole or FrankenPHP exist, you understand the importance of keeping applications in memory. I choose Nginx Unit because it provides a specialized application server experience for PHP, Python, and Go. The testing used Symfony 7 and K6 to run load tests with 10, 100, and 1000 concurrent connections. The benchmark compared Nginx Unit to Apache with libapache2-mod-php and Nginx with PHP-FPM. Testing ran with 20, 50, and 100 clients per second during one minute. These traditional setups showed almost the same results when the workload stayed low. Does Nginx Unit ever match the extreme speed of Swoole?

Managing workloads through the API

The Nginx Unit configuration relies on a control API to manage listeners and routes. A listener accepts requests on a socket and passes them to a destination via variable interpolation. You can configure the processes object to manage worker counts dynamically. When an application load rises, Nginx Unit creates more application processes, but the system never exceeds the total number of workers you defined by setting the max parameter within the processes object for that specific application. The spare parameter defines how many workers stay active during low load. The idle_timeout parameter dictates how many seconds Unit waits before it terminates an idle worker. Nginx Unit also allows MIME filtering in routing schemes. It uses TLS to handle certificate bundles and supports Server Name Indication. Since version 1.23.0, Unit handles SNI using an array of certificate bundle names for the certificate option value. If a client sends a server name, Unit responds with the matching certificate bundle. In version 1.24.0, Unit introduced the ability to use built-in and customizable MIME types in routing schemes. This allows users to separate static content from PHP scripts within a single share action. It also provides the ability to chroot or restrict path resolution on Linux systems running kernel version 5.6 or higher.