4 ms·

You mitigate this by taking boxes out of your response pool, deploying, then putting them back in. I generally do 50% deploys at a time. Solves this issue eleg

You mitigate this by taking boxes out of your response pool, deploying, then putting them back in. I generally do 50% deploys at a time. Solves this issue elegantly.

kijin 5y ago
Been doing that for a while, but it's a workaround at best insofar as the opcache bug is concerned. I wouldn't call it elegant. A thing that calls itself a cache should be able to handle evictions without throwing up. It's also the kind of workaround that isn't applicable to the vast majority of PHP sites out there: beginners running WordPress on a single box. One day, you update a few plugins like a good security-minded person should do, and this causes a bunch of cache invalidations. Bam! The site is down and the error messages aren't helpful. It really doesn't help bolster PHP's reputation as a stable, beginner-friendly language.
- 0x0nyandesu 5y ago
  Shared hosting is kinda bottom barrel these days. Even one off static sites I'd isolate into $5/month digitalocean droplets over shared hosting precisely for this reason. PHP is optimizing more for large sites that use multiple servers because frankly that use case is more important.
  - kijin 5y ago
    The opcache bug is actually more likely to hit VPS and dedicated servers, because most sites on shared hosting don't have enough concurrency to trigger the race condition. The last time I helped a customer fix it, they had a cluster of EPYC servers. Their app needed scratch space for generated code, so even offline deployments wouldn't prevent garbage from accumulating in the local opcache, eventually causing a restart. Even up here in the clouds, there are many times more people who rely on one-click WordPress-preinstalled droplets than there are people who understand how to correctly juggle multiple droplets to deploy updates without downtime. Besides, a bug in the PHP runtime is a bug in the PHP runtime, regardless of whether the user is following today's best practices.

You mitigate this by taking boxes out of your response pool, deploying, then putting them back in. I generally do 50% deploys at a time. Solves this issue elegantly.

kijin 5y ago

Been doing that for a while, but it's a workaround at best insofar as the opcache bug is concerned. I wouldn't call it elegant. A thing that calls itself a cache should be able to handle evictions without throwing up. It's also the kind of workaround that isn't applicable to the vast majority of PHP sites out there: beginners running WordPress on a single box. One day, you update a few plugins like a good security-minded person should do, and this causes a bunch of cache invalidations. Bam! The site is down and the error messages aren't helpful. It really doesn't help bolster PHP's reputation as a stable, beginner-friendly language.

0x0nyandesu 5y ago
Shared hosting is kinda bottom barrel these days. Even one off static sites I'd isolate into $5/month digitalocean droplets over shared hosting precisely for this reason. PHP is optimizing more for large sites that use multiple servers because frankly that use case is more important.
- kijin 5y ago
  The opcache bug is actually more likely to hit VPS and dedicated servers, because most sites on shared hosting don't have enough concurrency to trigger the race condition. The last time I helped a customer fix it, they had a cluster of EPYC servers. Their app needed scratch space for generated code, so even offline deployments wouldn't prevent garbage from accumulating in the local opcache, eventually causing a restart. Even up here in the clouds, there are many times more people who rely on one-click WordPress-preinstalled droplets than there are people who understand how to correctly juggle multiple droplets to deploy updates without downtime. Besides, a bug in the PHP runtime is a bug in the PHP runtime, regardless of whether the user is following today's best practices.