PHP processes

# PHP processes

Unlike frontend JavaScript, which is usually running in the web browser, PHP scripts are executed on the web server, and the output is then usually delivered to the web page as HTML. A PHP FPM process is a reserved computing resource - think CPU. Each PHP process can respond to one concurrent PHP request at a time.

fortrabbit utilizes FPM (FastCGI Process Manager). Unlike with php-cgi the PHP FPM process stays alive. Besides the allocated PHP memory, a number of persistent FPM PHP processes is spawned with each plan. See the PHP component article.

# PHP memory requirements

How much memory your website will require depends on multiple factors. Let's start with the theory:

• Extensions: Each enabled PHP extension must be loaded into memory.
• PHP libraries: You most likely are using Composer to manage your dependencies. This implies a set of PHP files which need to be interpreted and loaded into memory - specifically into the OPcache.
• PHP code: The code you write yourself consumes memory in the OPcache as well. The more code you have, i.e. the more functions and complexity, the more memory is required.
• Runtime variables: In each request your App fills variables ($foo = "bar"), which consumes memory. How much it will use depends on the amount of data used in variables. You can measure how much you are by calling memory_get_peak_usage().

Now, the memory used by extensions and OPcache is shared. This means: If you run an app on a single process and use 10 MB OPcache, then you will also only use 10 MB of OPcache with two processes. The memory consumed by runtime variables is not shared. It's hard to pre-calculate the expected memory usage.

The tricky part is the data size. Say you have a blog with comments using a database. Now rendering a small blog entry with no comments will utilize less memory than rendering a large blog entry with thousands of comments. Or does it? Well, it really strongly depends on your design and actual code. For example, you could load all of the thousands of comments into a PHP array and then render the site or you could load them one by one and print them out immediately - both would have a different impact on memory. In general the memory usage will change over the lifetime of your App - expect it to increase with growing data size.

# PHP processes, PHP requests, PHP response time

• By design PHP requests should only take a very short time to execute.
  • If it takes longer, it's likely your code is slow. Refactor it for performance!
• Aim for 250 ms or less on average.
  • Our dashboard shows you PHP response time metrics.
• A new incoming PHP request will have to wait if all PHP processes are busy.

# A simple example

• Your App has 2 PHP processes
• 1 PHP request takes 500 ms to execute (PHP response time)
• So each PHP process can handle 2 PHP requests per second
• Since there are 2 PHP processes, the App can deliver 4 PHP requests in 1 second

# A bad example

• Your environment has booked 4 PHP processes
• 1 PHP request commonly takes 1000 ms (1 second) - which is too long
• 1 page view of your website creates 3 PHP requests
• 3 website visitors at the exact same time can bring the website down

# PHP processes VS page views

Page views refer to a single request made by a user to view a page on a website. This request will likely involve a number of HTTP requests, such as images, HTML, CSS, and JavaScript files, all of which must be downloaded from the Apache web server.

A page view will likely also require the server to execute any PHP scripts associated with the page, which translates into one PHP process for each PHP script.

For many websites the ratio between page view and PHP request is one to one. But often one page view will generate multiple PHP requests, for instance by making different AJAX calls to the backend to query the database, returning API requests, or transforming images.

# PHP processes VS max execution time

Sometimes clients ask us in support to increase the max_execution_time. While this might help to execute long-running tasks, this also blocks PHP processes for a longer time. See the examples above. That's why we usually recommend lowering the time it takes to execute PHP to be able to serve your website to your visitors simultaneously.

# TTFB and PHP response time

For web server performance "PHP response time" is an important metric. It can be roughly translated to the Time To First Byte, which also includes network latency effects. Most websites should be able to attain a "PHP response time" of 250ms or even less. This is possible with attention to best practices.