PHP requests per IP
Now that the new year has begun and the holiday season is coming to an end we’re lifting the deployment halt for this year. Like always, we’ve abstained from making big changes to the Hypernodes in the last couple of months to facilitate smooth sailing during the busiest period in E-commerce. But now that that’s over, we once again have a nice new update to streamline your shop’s performance.
Change in maximum amount of PHP-FPM workers
In this release we set the maximum amount of PHP-FPM workers that can be used by one IP to 20. In 2016 we released a change that limited the amount of PHP-FPM workers to be used by one IP to all workers but two. During this holiday period we noticed that for large Hypernodes this limit leaves something to be desired for shops that are approaching their limit.
The amount of FPM workers that your Hypernode has is currently defined by the formula vCPUs * 5. For small Hypernodes the previous arrangement makes sense because then no one IP can hog all the slots. If you have five workers, then two will always be free to be used by other IPs.
For larger shops we often see that there’s a lot of requests to administrative pages from one IP. It is common that at the office of the retailer or of the web developer a lot of people are working on the same site. For that case we shouldn’t be too eager to limit requests per IP*.
Advantage for larger Hypernode plans
But because our larger plans have a lot of cores, the amount of PHP-FPM processes that one IP could potentially legitimately use becomes unrealistic. For our Excellence XXXL plan with 40 cores the amount of running PHP-FPM workers available on the system would be 200. One IP could then theoretically use 198 workers (ignoring all other rate-limit mechanisms). Under no circumstances that should be normal behavior.
The next update will set an upper limit of 20 workers per IP. For smaller plans this won’t change anything, but for all plans with more than four cores this will help more fairly distribute the server’s computing power among visitors if there are situations where one visitor does a lot of slow processing requests.
Like with the previous rate-limit, users that overstep this threshold will receive a 429 Too Many Requests status code.
* Note that you can always disable the per IP rate limit for a specific IP in the NGINX config if you want to whitelist your office.
Block unwanted bots via Byte Service Panel
We made it easier for our customers to block bots that have a negative impact on the performance of a shop. You now have the option to block certain user agents via the Byte Service Panel. For more information, please read this article on how to block user agents.