One of the most common issues you’ll experience hosting with Kinsta is reaching the PHP Worker Limit. Reaching the PHP worker regularly can result in slow performance, or worse with downtime.
In this guide we’ll walk you through how to resolve those issues.
What is a PHP Worker?
Think of a PHP worker like a car on a highway. The more lanes there are on the highway, the more cars it can handle. The Starter plan at Kinsta includes two PHP workers so think of that as a highway with two lanes passing through it. Too many cars would cause traffic (slow performing site) and the only way to resolve the traffic jam is by either reducing the number of cars that enter the highway, and/or increasing the number of lanes the cars pass by.
While we’re not going to cover the technical details of what a PHP worker is, note that several hosting companies are moving towards limiting PHP workers rather than other metrics to price their plans. While it’s a better metric for hosting providers for cost reasons, it’s a confusing metric for customers and how to reduce their usage.
How to Check PHP Worker Limits
It’s normal to see some PHP worker limits exceeding their limits. Not all limits are treated equally and can be difficult to see the graph be at zero. Don’t panic if you see limits being reached.
The above graph is a good example of PHP workers being met, but we’re not having any performance issues on the site. What the graph is telling us is that it met the limit fifty six times over the course of 24-hours. It does not mean it used 56 workers. If we had 8 PHP workers, it means that it went over the 8 PHP workers fifty six times during that period.
What’s likely happening here is the PHP worker limit was met for a few milliseconds and immediately cleared up. This may have occurred during plugin updates or while logged in performing other admin tasks. There’s no way to distinguish from this graph whether those 56 times it went over the PHP workers were from a few milliseconds or a more severe case of several seconds thus resulting in errors or performance issues.
How can you tell if the site has been going down as a result of PHP workers? Check the response codes.
The image above shows that there’s been zero 500 errors for this site. You would see 500 errors if the PHP workers limit is creating downtime. It doesn’t mean that you shouldn’t try to reduce your PHP worker limits, but it’s a good start in determining the severity of the issue.
Block Bots
Blocking bots helps reduce unnecessary resource usage to allow more resources for your real visitors. Kinsta does not allow you to enter NGINX rules so you’ll need to reach out to support to add the following rules. Keep in mind these will block many services so look through the list to ensure it’s not blocking a service you’re actually using. Most on the list are bad bots though.
if ($http_user_agent ~* "SemrushBot|Semrush|AhrefsBot|MJ12bot|YandexBot|YandexImages|MegaIndex.ru|BLEXbot|BLEXBot|ZoominfoBot|YaK|VelenPublicWebCrawler|SentiBot|Vagabondo|SEOkicks|SEOkicks-Robot|mtbot/1.1.0i|SeznamBot|DotBot|Cliqzbot|coccocbot|python|Scrap|SiteCheck-sitecrawl|MauiBot|Java|GumGum|Clickagy|AspiegelBot|Yandex|TkBot|CCBot|Qwantify|MBCrawler|serpstatbot|AwarioSmartBot|Semantici|ScholarBot|proximic|MojeekBot|GrapeshotCrawler|IAScrawler|linkdexbot|contxbot|PlurkBot|PaperLiBot|BomboraBot|Leikibot|weborama-fetcher|NTENTbot|Screaming Frog SEO Spider|admantx-usaspb|Eyeotabot|VoluumDSP-content-bot|SirdataBot|adbeat_bot|TTD-Content|admantx|Nimbostratus-Bot|Mail.RU_Bot|Quantcastboti|Onespot-ScraperBot|Taboolabot|Baidu|Jobboerse|VoilaBot|Sogou|Jyxobot|Exabot|ZGrab|Proximi|Sosospider|Accoona|aiHitBot|Genieo|BecomeBot|ConveraCrawler|NerdyBot|OutclicksBot|findlinks|JikeSpider|Gigabot|CatchBot|Huaweisymantecspider|Offline Explorer|SiteSnagger|TeleportPro|WebCopier|WebReaper|WebStripper|WebZIP|Xaldon_WebSpider|BackDoorBot|AITCSRoboti|Arachnophilia|BackRub|BlowFishi|perl|CherryPicker|CyberSpyder|EmailCollector|Foobot|GetURL|httplib|HTTrack|LinkScan|Openbot|Snooper|SuperBot|URLSpiderPro|MAZBot|EchoboxBot|SerendeputyBot|LivelapBot|linkfluence.com|TweetmemeBot|LinkisBot|CrowdTanglebot") { return 403; }
Need to go in deeper and familiar with how to use SSH? The following two commands will help provide a list of user-agents currently visiting the site.
cd /www/*/logs && awk -F'"' '/GET/ {print $6}' access.* | cut -d' ' -f1 | sort | uniq -c | sort -rn
cd /www/*/logs && grep -i "bot" access.* | awk '{ print $2,$12,$13,$14,$15 }' | sort -n | uniq -c | sort -nr | head -25
Add Cloudflare
Kinsta by default has Cloudflare already but adding your own on top of theirs will provide additional rules and settings you can add to limit the bad traffic that comes in. You’ll want to learn how to add Cloudflare Page Rules if you’re interested in limiting traffic from regions or bad behaviour.
Block Countries
Blocking entire countries is useful if your website is for a specific region and you don’t need visitors from another location. For example, if you run a local business in Spain, perhaps you don’t need visitors from China visiting your site. This can save a significant amount of resources on the site.
There are two ways you can block entire countries. One is through the server and another is via DNS using Cloudflare Page Rules. I recommend reaching out to Kinsta Support to block it at the server level along with the list of countries you’d like blocked. Start by blocking countries that are currently visiting the site.
Go to Analytics > Geo & IP to review the list of countries currently visiting. Unfortunately, Top Cities is not very useful as it doesn’t include the country and may include the datacenter location the website is hosted with too.
If you only want visitors from a specific country visiting your website, you can also ask to block the entire world except the country you specify. Keep in mind that Google may want to crawl your site from its USA based datacenters thus would be wise to keep USA unblocked.
In addition to saving resources, you’ll be saving the number of visitors that reach the site that Kinsta allows on your plan.
Upgrade Plan
The number of PHP workers allowed per site is determined by the plan you’re on. If you have any sort of dynamic site, like an ecommerce site, you’ll need a minimum of Business 1 plan which includes 4 PHP workers.
Host With Us!
At Reggio Digital, we have a higher plan that allows for additional PHP workers. We have several sites on our plan. Looking for more PHP workers at a cheaper cost? Reach out to us!
Optimize Plugins and Features
Be smart about the plugins used on the site and the resources they consume. Disable and delete any unused plugins as those features could be utilizing PHP workers.
Cache All The Things
By default on Kinsta, all query strings like example.com/?=something will not be cached. Google Analytics often uses strings like ?=utm_source for tracking purposes. But because these strings are not cached, they increase resources by a significant amount. It’s best if these are cached to save on resources.
To cache these requests, you will need to ask Kinsta Support to implement their standard rule to cache all Google and Facebook related query strings in their force cache rules. There are no downsides to implementing this.
I recommend reviewing Top Cache Bypass URL’s by visiting Analytics > Cache > Top cache bypasses section too if there’s anything else to force cache.
There should be a few normal bypasses shown in there. Kinsta already has rules in place for WordPress core, WooCommerce, and Easy Digital Downloads to not cache. /wp-admin/, /my-account/, /checkout/, and /cart/ are a few that are already bypassed. If you’re using a plugin like MemberPress or have any other pages that should not be cached, you can ask Kinsta support to bypass those pages. You cannot however bypass the frontpage, nor the entire site. It must be only for specific posts/pages.
Remember that it’s normal and expected that logged in users are not cached.
Investigate with APM
Temporarily enable the Kinsta APM tool to find where the issues are. This will provide information on what exactly is consuming resources on the site from the time the tool is enabled. Also read Using Kinsta APM to Diagnose Performance Issues.
There’s a warning before enabling that states enabling this feature may affect performance on the site. The benefits of temporarily enabling this feature far outweighs not knowing this information. APM tools are also best enabled when the site is receiving the most traffic thus don’t enable it during off hours as that data won’t be as useful. Regardless, the performance hit from this tool is nearly zero and you are unlikely to notice a difference.
Check Error Logs
Check your error logs if there’s an issue that could be negatively affecting performance. Kinsta provides the logs in the front-end by going to Logs and making sure error.log is selected in the dropdown box. Even if you’re not a developer, you can vaguely understand where the issue is coming from by checking the file path of where the issue is coming from. It could be pointing to a plugin path for example which you can then test by disabling the plugin mentioned from the logs.
You may see something like the following in the error logs:
2022/04/30 17:24:40 [error] 48159#48159: *110993 access forbidden by rule, client: 20.24.56.102, server: whattoeatin.com, request: "GET /.aws/credentials HTTP/1.1", host: "whattoeatin.kinsta.cloud:48723"
This is normal and indicates that Kinsta blocked a bot trying to fish for vulnerable files.
Upgrade PHP Version
Unfortunately, Kinsta defaults to PHP 7.4. Consider moving sites to PHP 8.0, and if possible to PHP 8.1. PHP 8.0 performs significantly faster and is the new default from several hosting companies. PHP 7.4 will end support by the end of 2022. You can do this by going to Tools section. It’s easy enough to switch back if you encounter any issues.
Still Need Help?
We’ll host your site with our Kinsta plan and we’ll help take care of your PHP worker issues.
