3 ms·

>There's no having to worry about restarting processes since the next request picks up the code changes and deploying at scale has so many problems auto-solved

>There's no having to worry about restarting processes since the next request picks up the code changes and deploying at scale has so many problems auto-solved by that such as rolling restarts. Nearly any serious PHP deployment will use an opcode cache which has to be invalidated, though maybe they are smart enough to do that from the filesystem now. >On the flip side, for single server deploys, you can also get by with zero down deploys without needing to set anything up Mod_python works about the same as mod_php although you are right insofar as most advice is to use a separate uWSGI process. >You can then handle things like percent based feature roll outs at the application level which is likely where it belongs anyways. You want incremental rollout essentially every time you change code; if you feature flagged every single change, you'd have your codebase's entire history all hanging out on master, with far too many possible combinations of feature flags to ever test. The nice thing about rolling back and forth with code is that each version is internally coherent.

nickjj 6y ago
> Nearly any serious PHP deployment will use an opcode cache which has to be invalidated, though maybe they are smart enough to do that from the filesystem now. Etsy has a massive PHP deployment. In one of their talks they mentioned one of the main perks of using PHP is they can just drop code onto a server and be done with it. They are operating at pretty crazy scale. Even deploying to hundreds of servers can happen very very quickly since you don't need to step through a tiered rolling restart. > You want incremental rollout essentially every time you change code; if you feature flagged every single change, you'd have your codebase's entire history all hanging out on master, with far too many possible combinations of feature flags to ever test. Often times you want to restrict features or certain things based on business logic in your app, not just a "dumb" load balancer. For example, you might want to enable new things for specific users who opt into a beta program or maybe only staff to start. But it could also be to a % of users. Usually the idea is to feature flag bigger things and once it's rolled out fully you remove the flag and now it's just something that exists all the time. Of course this depends on your organization tho.
zerocrates 6y ago
The standard settings for PHP's built-in opcode cache will automatically invalidate cache entries based on file timestamps, though setups trying to eke out maximum performance may disable this and therefore require manual invalidation.

nickjj 6y ago

> Nearly any serious PHP deployment will use an opcode cache which has to be invalidated, though maybe they are smart enough to do that from the filesystem now. Etsy has a massive PHP deployment. In one of their talks they mentioned one of the main perks of using PHP is they can just drop code onto a server and be done with it. They are operating at pretty crazy scale. Even deploying to hundreds of servers can happen very very quickly since you don't need to step through a tiered rolling restart. > You want incremental rollout essentially every time you change code; if you feature flagged every single change, you'd have your codebase's entire history all hanging out on master, with far too many possible combinations of feature flags to ever test. Often times you want to restrict features or certain things based on business logic in your app, not just a "dumb" load balancer. For example, you might want to enable new things for specific users who opt into a beta program or maybe only staff to start. But it could also be to a % of users. Usually the idea is to feature flag bigger things and once it's rolled out fully you remove the flag and now it's just something that exists all the time. Of course this depends on your organization tho.

zerocrates 6y ago

The standard settings for PHP's built-in opcode cache will automatically invalidate cache entries based on file timestamps, though setups trying to eke out maximum performance may disable this and therefore require manual invalidation.