Live Blog

Finding the Correct PHP-FPM pm.max_children setting for WordPress

Content Error or Suggest an Edit

Notice a grammatical error or technical inaccuracy? Let us know; we will give you credit!

Introduction

I saw the following posted online, and thought I’d respond to it, and felt that it would be good content.

I did a Google search on pm.max_children to read up a bit more on this setting, and the search results were the opposite. Instead of calculating max_children as a product of CPU, many articles suggest setting it depending on average process size and total memory.

I’m getting a bit of mixed signals here. But I’d like your thoughts.

For example, this random article: Finding the correct pm.max_children settings for PHP-FPM – Chris Moore

PHP-FPM pm.max_children for Various WordPress Loads

For example, this random article: Finding the correct pm.max_children settings for PHP-FPM – Chris Moore

It’s funny the comments are closed. I would have responded. This article specifically and only speaks to memory usage, which is important, but just one side of the equation. The article doesn’t mention WordPress anywhere, so perhaps they’re basing the information off of a different application or wordload.

For instance, I had to deal with a PHP application that would query 1 million records in MySQL, and manipulate the data. This required 2-4GB of memory for each process, this isn’t what WordPress does out of the box.

WordPress Workloads Breakdown

For most brochure sites, this is the typical workload.

  • Hitting the cache for 100% of requests, no worker required.
  • You use a worker to refresh the cache when it expires or the content is updated.
  • WordPress Admin Logins requires a worker.
  • Are resource based attack, which could be a bot or crawler hitting random pages that bypass cache or the requests have a query string (eg Events Calendar).

If you run WooCommerce, Membership site or you have logins enabled. You’re using workers more frequently.

WordPress and PHP-FPM Memory Utilization

Where memory becomes and issue is on larger sites, where you’re doing reports on data that is massive. For instance, WooCommerce reports on orders where there are 15,000 orders and 20,000 users. You’ll run out of memory.

Most requests for WordPress are within 100-500MB of memory.

Calculating PHP-FPM Workers based on CPU Cores

As for calculating how many workers per CPU. It all depends on the CPU, is it an 8 year old CPU or 1 year old CPU? is it a High frequency CPU? From there you can then figure out how many workers per core. Typically you can load 2-4 workers per core. On higher end CPU’s and bare-metal it’s 5-20.

A good guide is to separate your WordPress sites by type, Static (brouchure) and Dynamic (WooCommerce and Membership).

Static sites don’t need more than 2-4 workers, dynamic might need 4-40 denpending on their traffic.

You’re going to struggle more with resource attacks, more than anything. A static site can handle massive amounts of traffic if it’s cached properly. Dynamic is a whole other ball game.

For high traffic static sites, the typical culprit for high loads is WordPress redirects. You need to make sure you have your webserver redirect www to non-www and vice versa, and trailing slashes. If you get an influx of traffic, and you have no dynamic parts, then it’s quite possibly these two issues.

0 Shares: