PHP

PHP workers

PHP workers process a site’s PHP code. This includes building pages, processing background tasks, querying the database, etc.

One way to think of PHP workers is like employees at a store. Each worker can only handle one request at a time. If there are more customers than there are workers, those customers (processes) have to line up and wait for the next available worker to handle their request.

PHP workers really come into play when a site doesn’t or can’t cache most of its content. The more dynamic a website is, the more PHP workers it will likely need. Cached content doesn’t require PHP workers; they’re really only needed when the site needs to query the database to get or change information.

When it comes to WordPress performance, more PHP workers do not automatically mean better performance; there are a number of factors that you must consider:

• Caching: Effective caching can reduce the workload on PHP workers by serving cached content instead of dynamically generating it for each request. This can significantly improve performance, especially for frequently accessed resources.
• Hardware: The available hardware resources on the server, such as CPU, memory (RAM), and disk speed, directly impact PHP worker performance. Insufficient resources can lead to slower processing times and degraded performance.
• Web Server Setup: The configuration of the web server and its interaction with PHP can influence worker performance.
• Database Speed: PHP applications frequently retrieve data from MySQL databases to render dynamic content. The speed at which data is retrieved is influenced by things like how the database is organized, how queries are optimized, and how well the database server performs. This directly impacts how well PHP applications run.
• PHP Version: Newer PHP versions can often result in better PHP worker performance due to performance enhancements, bug fixes, and security updates.

At Kinsta, we value the importance of your site’s performance. That’s why we’ve implemented various technologies aimed at maximizing PHP performance and minimizing PHP requests:

• We offer page caching at both the CDN and server levels, with customizable rules to ensure maximum cache efficiency.
• We use premium servers at GCP (C2 and C3D virtual machines) equipped with Google Cloud’s fastest CPUs to help your site’s PHP workers run more efficiently.
• Our scalable infrastructure ensures that your WordPress site’s PHP workers have enough CPU resources to operate at peak performance.
• We utilize a premium network infrastructure at Google Cloud Platform (GCP) to minimize latency. By leveraging GCP’s premium network, we significantly reduce the time it takes for data to travel between different components of our infrastructure, including the MySQL server and web servers.
• We provide a highly optimized MySQL server hosted locally to reduce network latency and improve data retrieval and processing speeds.
• On the MySQL server, we have InnoDB buffers to help improve database performance by reducing disk I/O operations. Data can be accessed more quickly from memory rather than from disk, enhancing the efficiency of read and write operations and resulting in better overall performance for the MySQL database.
• We ensure the latest version of PHP is always available to incorporate any performance enhancements.

PHP workers vs. PHP memory limit

The number of PHP workers should not be confused with the PHP memory limit. PHP workers are individual PHP processes that handle incoming web requests, whereas the PHP memory limit specifies the maximum amount of memory (RAM) a single PHP script can use during execution.

PHP workers manage concurrency by processing multiple requests simultaneously, whereas the PHP memory limit manages resource allocation by restricting the memory usage of individual scripts. This prevents any single script from using all the server’s available memory.

PHP memory limits are important for scripts requiring substantial memory, such as those performing large database queries, handling large file uploads, or executing complex calculations. If you encounter memory limit errors on your site, increasing the number of PHP workers won’t resolve this issue. Instead, you need to check your memory limit and, if necessary, increase it or purchase a memory limit add-on.

WordPress and PHP workers

An uncached request on a WordPress site usually goes something like this:

1. A visitor visits a page or performs an action on a page (e.g., adding something to a cart, submitting a form, etc.).
2. The web server (Nginx here at Kinsta) receives that request.
3. Nginx passes the request to PHP.
4. PHP queries the MySQL database and gets the information it needs or makes any updates needed.
5. PHP then uses your theme’s PHP files (and any plugin files if applicable) to generate an HTML page.
6. PHP hands the rendered HTML page back to the web server.
7. The page is served to the visitor.

In the process described above, Step 4 is the most time and resource-intensive (CPU and RAM). A well-optimized site with efficient PHP code and database queries will process that step fairly quickly.

On the other hand, poorly written or unoptimized PHP code and/or a lot of inefficient database queries will take much longer to get through Step 4. Requests that take longer to process monopolize PHP workers for longer periods of time.

Estimating the number of PHP workers needed

How many workers a site needs depends on several factors, such as: how dynamic the site is, how optimized the site’s code is (how quickly requests can be processed), and what kind of traffic the site receives. An optimized site handles requests quickly, freeing up PHP workers for the next request in the queue.

Dynamic sites like ecommerce stores, forums, learning sites, and membership sites will usually need more PHP workers than more static, brochure-type sites. Also, the busier a site is, the more PHP workers it will usually need.

Kinsta plans and PHP workers

The following tables show how many PHP workers are included by default in each plan at Kinsta:

Single-site plans

Multiple-site plans

We also offer custom plans where you can advise how many PHP workers you require. For more information, contact our sales team.

PHP workers, CPU, and RAM

When adding PHP workers, CPU and RAM resources must be taken into account. If you increase PHP workers, but the server needs more CPU and RAM to support those workers, this will create a bottleneck because the requests won’t be handled efficiently.

Here at Kinsta, our custom LXD containers are configured with plenty of CPU and RAM resources. Additionally, by using compute-optimized C2 and C3D virtual machines equipped with Google Cloud’s fastest CPUs, we help your site’s PHP workers run more efficiently. Our scalable infrastructure ensures that your WordPress site’s PHP workers have enough CPU resources to operate at peak performance.

Identify performance issues related to PHP workers

If too many requests stack up in the queue because of a large influx of requests, long-running processes, or a combination of both, the site can experience performance issues that may result in 502 or 504 errors.

Using tools like Kinsta’s APM tool and the Query Monitor plugin can help you identify performance issues and slow queries. We also recommend working with a qualified performance expert to diagnose issues.

PHP worker limit

You can access the  PHP worker limit chart in MyKinsta > WordPress Sites > sitename > Analytics > Performance > PHP worker limit. If a PHP worker doesn’t have anything to do for 10 continuous seconds, the PHP worker process will automatically terminate. As soon as it is needed again, the worker process will be recreated instantly. This chart shows you how many times the maximum number of allocated workers has been reached on your site.

For example, if you have a WP 5 plan, this allows for a maximum of 4 PHP worker processes. If 3 PHP workers are in use and another request is made to your site that requires a PHP worker, when the PHP worker is created, it reaches the maximum number of 4 PHP workers and is logged as an incident where the PHP worker limit is reached.

This may only give you a partial picture of your PHP worker activity as this only records the number of times the PHP worker limit is reached and not how long all PHP workers were in use.

For example, if your site experiences a surge in traffic, all PHP workers might remain consistently busy for an entire hour with no idle time and, therefore, do not terminate at all during that hour. This would only record as one instance of the PHP worker limit being reached, and therefore, it may seem like the PHP workers weren’t occupied during that hour when, in fact, they were all active the entire time. After 30 minutes, if there’s a decrease in traffic allowing one PHP worker to be idle for 10 seconds, it will automatically terminate. However, if the PHP worker is needed again in another minute, the maximum number of PHP workers would again be reached, resulting in another PHP worker limit being logged.

If you are investigating website performance and determining if your site is continuously using up its PHP workers, you can monitor PHP worker activity using tools in an SSH session. For example, the following custom command monitors the number of active PHP workers every 0.3 seconds:

watch -n 0.3 "ps aux | awk '\$(NF-2) ~ /php-fpm/ && \$(NF-1) ~ /pool/ && \$8 ~ /R/ { print \$0 }' | wc -l"

To exit this command, press CMD + C or CTRL + C then release both keys.

Cache analysis

The cache analysis section in MyKinsta cache analytics can be used to view your site’s total cached requests and top cache bypasses.

Reduce and optimize PHP worker usage

Caching

Caching is your best friend when it comes to optimizing your site and reducing the number of PHP workers needed. Remember, PHP workers aren’t needed for cached content, so cache everything you can.

Page caching

At Kinsta, we take care of page caching for you; all sites use Nginx’s FastCGI cache module for super-fast performance.

Object caching

Adding a persistent object cache like Redis in front of your database can boost performance and reduce the need for PHP workers. Without object caching, MySQL database queries are executed for each request, even when it’s the same query and results.

Redis stores the results of database queries in RAM so PHP can grab those results without running the query again. Removing the need for repetitive database queries allows PHP workers to conserve resources and fulfill requests more efficiently.

Check out our premium add-ons to learn more about adding Redis cache to your site.

Code optimization

Make sure your site’s code is optimized so it is as efficient as possible. This applies to custom code, theme code, and plugin code. If you’re not sure, we recommend asking a developer to review your site’s code.

Custom code

If your website contains any custom code snippets in plugins or your theme, make sure they’re truly necessary and well-written.

Plugins

Take a good look at the plugins used on the site and make sure they’re truly needed, don’t duplicate features, and are the best option for the need they fulfill. If any plugins aren’t compatible with the latest version of WordPress and PHP, it may be time to consider other options. If you have plugins on your site that aren’t being used, removing those is recommended.

Theme

Use a lightweight and performant theme. Avoid themes that contain functionality that’s best implemented via separate plugins (e.g., SEO, search filtering, custom fields, image sliders/slideshows, etc.) or isn’t needed for your site.

Update PHP

Use the latest PHP version for faster performance. PHP benchmarks show that each PHP version is faster than the previous one.

Enable Kinsta’s CDN

Enabling Kinsta’s CDN provides another boost of efficiency and optimization for your site. Kinsta’s CDN is our high-performance HTTP/3 CDN powered by Cloudflare, provided to you at no additional cost. With it enabled, your site will be able to serve static assets from locations across the world.

Consult with a performance expert

If you’re familiar with site optimization, this is an optional step. An expert can help you analyze all aspects of your sites, identify bottlenecks, and implement solutions.

Restart PHP

If PHP goes down, our system automatically logs this for our Systems Administration (sysadmin) team to check out. However, you can manually restart PHP for any of your websites individually with a simple click of a button from MyKinsta.

How to restart PHP manually

To restart PHP on your WordPress site, follow the steps below.

1. Log in to MyKinsta.
2. Go to WordPress Sites and select the site on which you’d like to restart PHP.
3. Go to the Tools tab and find the Restart PHP section.
4. Click the Restart PHP button.

Please note that restarting PHP will take about 5-10 seconds. You will receive a notification at the bottom of the screen when it is completed.

Note: You will also need to delete your site’s cache to see the changes.

PHP limits

As a Managed WordPress service, Kinsta has the optimal PHP settings configured to work best with WordPress sites. If you have specific PHP requirements, feel free to reach out to our Support Team to discuss your needs.

Kinsta offers PHP 8.1, 8.2 and 8.3. These are the default settings for PHP:

• memory_limit = 256M
• post_max_size = 128M
• upload_max_filesize = 128M
• max_input_vars = 10000
• max_execution_time = 300

You may be able to increase these values if necessary. Please contact our Support Team to find out what options are available to you.

PHP memory limit

Kinsta’s default PHP memory limit is 256MB, which is more than enough for most WordPress plugins and sites. This limit exists to prevent PHP scripts from consuming excessive memory. If you set the limit too high, a misconfigured or broken script can cause serious issues by using up too much memory.

If your site is set up correctly at Kinsta, you shouldn’t run into a memory limit error. If you see this error, we recommend checking your WordPress settings to make sure it hasn’t been accidentally set too low.

If you want to increase a site’s PHP memory limit, you can purchase a PHP memory limit add-on. This add-on increases the memory limit from 256MB to 512MB at a cost of $50 per site per month.

To purchase this add-on, in MyKinsta, go to WordPress sites > sitename > Add-ons, and under PHP memory, click Change.

This opens up a new window with the pricing information; click Open chat to start a chat with our Account Management team, who will set up the add-on for you.

You can also contact the Account Management team via the live chat in MyKinsta Dashboard or by emailing us at [email protected].

If you remove the PHP memory limit add-on and you’re in the first 30 days of your WordPress Hosting plan, a prorated fee for the add-on will be added to your next invoice for the time period it was enabled. If your WordPress Hosting plan has been active for more than 30 days, you will receive a prorated credit for the add-on fees to your Account Balance for the remaining days of the current billing period. The credit is automatically used to offset money owed to Kinsta on your next invoice. For more information, refer to our WordPress Hosting Money-Back Guarantee.

Checking and changing your PHP memory limit

To check your current PHP memory limit for WordPress, log in to your site’s WordPress dashboard and navigate to Tools > Site Health.

Go to the Info tab and click the arrow icon next to the Server section to expand this section and view your PHP memory limit.

If the memory limit is lower than 256M, check your wp-config.php file to see if the WP_MEMORY_LIMIT has been modified and adjust it if needed.

If the memory limit is 256M, but you’re having issues with PHP memory, we recommend checking and testing plugins and themes. You can use a staging environment to safely deactivate and reactivate plugins and themes to identify the source of the memory usage.

If the error persists and you cannot identify the source, you can open a new chat with our Support team to check the logs and rule out any issues on the server side.

Updating PHP

We’ve made updating your site’s PHP version as easy as possible in MyKinsta.

In MyKinsta, you can update the PHP version for one or multiple sites, including staging sites, simultaneously from the WordPress Sites page. Select the checkboxes next to the site(s) you want to update the PHP version for, click Actions, and choose Change PHP version.

Select the version you want to update to and click Change PHP version.

Once the process is complete, a success message will appear.

You can also update the PHP version for a single site within WordPress Sites > sitename > Tools. Under PHP Engine, click on the drop-down and select the PHP version you want to update your site to.

In the Modify PHP version modal/pop-up that appears, click the Modify PHP version button to confirm the change.

At the end of the update, your PHP engine will be restarted, and the backend (WordPress dashboard) of your site may be down for a couple of seconds. The front of the site will remain up, and visitors will not experience any downtime.

While the update process is running, you can navigate to other parts of MyKinsta, but some actions, like cache management, will be unavailable until the PHP engine has restarted.

Once the update is complete (usually within 3 minutes or less), you’ll receive a notification in MyKinsta that it’s finished.

PHP Constants

PHP constants store fixed values that remain the same throughout your site. They are automatically global, which is ideal for values that need to be accessed in multiple places.

If you use a non-standard WordPress setup, such as Bedrock or Trellis, Kinsta may not be able to locate the DB_PASSWORD variable and, therefore, is unable to update the database password when you:

• Add a new site by cloning an existing environment
• Add a staging environment by cloning an existing environment
• Push staging to live
• Restore a backup
• Change the database password in MyKinsta

To resolve this issue, Kinsta provides the SERVER_SECRET_DB_PASSWORD PHP constant for use on the Kinsta servers. When you define this constant within the config.php file, MyKinsta uses it to identify your site’s database password. You can define it as follows:

define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB : 'asdijfhkjasdbfkjhbajiksd' );

You can define the following PHP constants to use with Kinsta servers:

• SERVER_SECRET_DB_USER
• SERVER_SECRET_DB_PASSWORD
• SERVER_SECRET_DB_HOST
• SERVER_SECRET_DB_NAME

For example, you can define the constants in the config.php file as follows:

define('DB_NAME', defined('SERVER_SECRET_DB_NAME') ? SERVER_SECRET_DB_NAME : 'newsitetest');
define('DB_USER', defined('SERVER_SECRET_DB_USER') ? SERVER_SECRET_DB_USER : 'newsitetest');
define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB : 'asdijfhkjasdbfkjhbajiksd' );
define('DB_HOST', defined('SERVER_SECRET_DB_HOST') ? SERVER_SECRET_DB_HOST : 'localhost');

Alternatively, you can define the constants as follows:

define('DB_NAME',SERVER_SECRET_DB_NAME);
define('DB_USER',SERVER_SECRET_DB_USER);
define('DB_PASSWORD',SERVER_SECRET_DB_PASSWORD);
define('DB_HOST',SERVER_SECRET_DB_HOST);

PHP modules

The following PHP modules are installed on your WordPress site on Kinsta by default:

• bcmath
• bz2
• calendar
• Core
• ctype
• curl
• date
• dom
• exif
• FFI
• fileinfo
• filter
• ftp
• gd
• gettext
• hash
• iconv
• igbinary
• imagick
• imap
• intl
• json
• libxml
• mbstring
• mysqli
• mysqlnd
• openssl
• pcntl
• pcre
• PDO
• pdo_mysql
• Phar
• posix
• readline
• redis
• Reflection
• session
• shmop
• SimpleXML
• soap
• sockets
• sodium
• SPL
• standard
• sysvmsg
• sysvsem
• sysvshm
• tokenizer
• xml
• xmlreader
• xmlwriter
• xsl
• Zend OPcache
• zip zlib

ionCube is not installed by default but can be enabled if your site is running PHP 8.1, 8.2, or 8.3 within MyKinsta > WordPress Sites > sitename > Tools > ionCube Loader > Enable.

If you have questions about a specific PHP module not included in the list above, contact Kinsta’s Support Team.