3 ms·

While I don't use PHP today, it always makes me wonder at deceptively easy it is to deploy a PHP app. There's no having to worry about restarting processes sin

by nickjj 6y ago

While I don't use PHP today, it always makes me wonder at deceptively easy it is to deploy a PHP app. 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. You can then handle things like percent based feature roll outs at the application level which is likely where it belongs anyways. On the flip side, for single server deploys, you can also get by with zero down deploys without needing to set anything up. Most other languages and frameworks can't do this, or the way they do it involves doing very complicated things or using even more complicated tools to solve the problem for you. It's funny to think back in the early 2000s I was using PHP and deploying was brain dead simple then, but fast forward almost 20 years and it's still pretty much the case today -- at least it seems that way based on the talks I've seen around using PHP in production over the years.

closeparen 6y ago
>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.

by nickjj 6y ago

closeparen 6y ago

>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.