12 ms·

But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend tha

by ddw 10y ago

But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.

increment_i 10y ago
At this point, I would have no problem arguing with a straight face that your choice of technology stack might be the least important factor in whether your business succeeds or fails. I don't mind if I get torched for this, it's just my current, non-Silicon Valley, non-substantiated opinion at this time (though I don't think it's without merit).
- deleted 10y ago
  [deleted]
jwatte 10y ago
The scalability of PHP is great, because each request is fully independent. This is like the Amazon lambda model. You /have/ to put your state in some storage back end, network attached RAM or such. This is a scalability best practice!
- haimez 10y ago
  Yeah, but you also have to fork a whole process per request to do it. Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request. I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.
  - justinhj 10y ago
    It is easy if you are just willing to spend more money on servers. Often it's worth it.
    - haimez 10y ago
      Only if you extract a ton of value per user or can serve a huge number of users per machine. Otherwise, upping the number of servers by an order of magnitude will start requiring an operations team to maintain. That was a pretty common truism 10 years ago, but machines haven't gotten faster at the same rate lately.
    - collyw 10y ago
      Its also a problem that has been solved a long time ago and is well understood. Unlike trendy microservice architectures....
    - nrser 10y ago
      it's the "good problem". and the good problem can always be solved, though lack of reliability can seriously hurt your growth. but that doesn't mean that it's as easy as people make it out to be. i wrote and ran a big php app (Zynga's Mafia Wars). this is just about the app server (apache + php side), single-master MySQL will give you far greater problems at that scale. everyone is tearing away adding features, and the code just keeps getting bigger. everything includes everything else. so you can't just start fresh with every request, it takes way too long. so you use APC or whatever. now you have global shared state (and people start using it), but as long as no one really fucks it up that's ok. php processes are always erring and dying in weird ways that no one can figure out, especially if anyone uses the half-baked OO stuff (circa 2008-9), and tracking down obscure php state errors ranges from difficult to impossible since you're never quite sure when or where something went wrong, but it works for most people most the time, as long as you remember to clear out the error logs so they don't get big enough to crash the box. memory use still sucks at around 30M a process, meaning you can only have around 500 workers on at 16G RAM server, but it's workable. at least it's not rails. because it takes a while to talk to even Memcache (go forbid you talk to MySQL) and do all your silly user updates (games are really write-heavy) you are taking a few hundred ms per request, so 16G mem servers (it's 2008) safely top out at around 500-600 req/sec, and i think would melt close to 1000 or so. remember, your throwing everything you have at growth and features so you're not really optimizing shit. cool, just need more hardware. which is no problem. if you can get hardware. when you're co-located it takes forever to get new hardware online. not really an option. and even the F5 load balancers can only take so much. and there are issue with getting too many app servers talking to too many memcache servers. or something like that. after i left i think they saturated the data drops, which really puts you in a bind. but that's not a problem now, with cloud services, right? except that those are not limitless either. i think FarmVille ran into a wall where AWS wouldn't / couldn't supply more instances (again, this was around 2009-10 so prob a lot better now). and those are still physical machines in physical datacenters somewhere that will have all the same problems and limitations and then some. but you're going to have problems with any app runtime at that scale. and php's performance was an order-to-two or magnitude better than rails, and we never figured out how to get significantly complex and traffic-heavy java apps to stop leaking memory. though i'm sure you can. and you will! like i said, it's all solvable. hell, even MySpace didn't fail because of tech infrastructure. what i'm saying is that php wasn't (and maybe still isn't?) particularly fun when throwing hardware at it doesn't work, and you end up losing a lot of the purity / simplicity of the model because it's too damn expensive. ffs, Facebook re-wrote the runtime. that's what it took for them. and my friends there tell me it's pretty much like writing java at this point. it's a fine choice, but i'd rather not use it again. had a much better time with python before javascript ate the world.
  - bartl 10y ago
    "fork" is not a major problem in PHP. In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code. That is what slows it down. It's remarkable that PHP still manages to do that in just 100ms. In Zend Framework it's slightly better because it includes an autoload option, which implies only PHP files that are actually used by athe request, get loaded. That way the overhead is "only" 50ms.
    - raarts 10y ago
      > In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code. This only proves Drupal is slow.
    - ransom1538 10y ago
      Wow. Is this comment from 2003? Uh. Why don't turn on opcache [1]? PHP7 is fast. Real fast [2]. http://php.net/manual/en/intro.opcache.php http://php.net/manual/en/intro.opcache.php https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-php-performance-benchmark-2016/ https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
      - igouy 10y ago
        > PHP7 is fast. Real fast [2]. < You need a lot more than a "Sieve of Eratosthenes" code snippet to back that up :-)
  - mtberatwork 10y ago
    > Yeah, but you also have to fork a whole process per request to do it. Eh, any PHP developer worth their salt is implementing PHP-FPM. The days of forking expensive Apache processes have long been over.
    - codedokode 10y ago
      And even whey they were not over yet there was no fork for each request. A pool of workers was forked beforehand, and each worker could handle requests one by one without restarting (only PHP environment is cleared, OS level process is not restarted).
    - xorcist 10y ago
      The whole reason your Apache was (kind of) expensive to fork was PHP. You've only moved that forking to the PHP-FPM process. But that said, forking processes is not really a problem unless you do really long lived connections (such as longpoll handlers). Many other languages do that. Not many other languages have kept the CGI-like request model that PHP has, though. It encourages things like parsing code or even opening database connections on every request, unless you cache them. (Which you probably do if you are a PHP developer. But it's not always as automatic as one would hope. Have you checked your application still fits in the cache you set up?)
yxhuvud 10y ago
Managers caring about technical debt? You must live in a parallel universe. They may care about maintenance costs, but that is not really the same thing.
- novaleaf 10y ago
  the end result of technical debt ==> maintenance costs makes it same enough.
  - GFischer 10y ago
    Looking at things from the other side: being a manager and trying to sell projects to reduce technical debt is really freaking hard in a world of short-term outlooks and revolving door of CEOs that want to improve numbers this quarter or the next, not a few years down the road.
  - sqeaky 10y ago
    This is entirely true, but I have never worked with someone beyond the leader of my immediate who though the same. Most managers don't care what cruft is in there when it ships.
- ddw 10y ago
  They don't until things break, your app can't handle the amount of requests coming in, can't insert and fetch data in a reasonable amount of time, etc. It's at this point that shit falls apart and the manager starts to care about these technical choices and all of the time and money that will be needed to be spent to rewrite. Call it maintenance costs if you want but those costs are directly affected by the technology decisions you make.
ransom1538 10y ago
Performance? You need to update your act. PHP7 is 3x faster than python and now faster than Java 8 . The only people that can call php slow are masochistic c++ web hacks. https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-php-performance-benchmark-2016/ https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
- jbergens 10y ago
  Funny that people complain about js performance. In this benchmark it was 3 times as fast as php7 and about 7 times as fast as java 8. Have not checked the details of the benchmark yet.
  - juliangoldsmith 10y ago
    It's worth noting that it's compiled JavaScript vs. interpreted PHP. With something like HHVM the PHP version would likely be a lot faster.
    - secoif 10y ago
      Compiled JavaScript?
      - niutech 10y ago
        I think he meant JIT compilation.
  - icedchai 10y ago
    Looks like you're reading that wrong? Java 8 is listed twice. Java 8, when using the non-standard library version of the program is second only to C++. This is pretty much as expected.
  - igouy 10y ago
    > Have not checked the details of the benchmark yet. < "Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!" ;-)
riprowan 10y ago
> But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels. I'm currently maintaining an app stack for a Fortune-100 company that, if I told you what it was, you simply wouldn't believe I was telling the truth. That's how out of date it is. "Scalability, performance, technical debt and quality" never entered into it. All anyone ever cared about was "does it get the job done and what does it cost to keep it running for another year as-is?"
- bmj 10y ago
  I'd upvote this many time if I could. I am in the same boat--my team helps maintain a ten year old web application that is used by the largest companies in our domain. The application is literally the backbone of data used by these companies to make money. We have reliability issues, and sometimes clients get a little upset, but every year it is the same thing: how much do we need to budget for support?
- TeMPOraL 10y ago
  > Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels. This. In my previous job, I was literally told by my boss, that they'd consider switching from PHP to something like Ruby or whatever, but PHP programmers are cheaper so that's why they stick with it.

by ddw 10y ago

increment_i 10y ago

At this point, I would have no problem arguing with a straight face that your choice of technology stack might be the least important factor in whether your business succeeds or fails. I don't mind if I get torched for this, it's just my current, non-Silicon Valley, non-substantiated opinion at this time (though I don't think it's without merit).

deleted 10y ago
[deleted]

jwatte 10y ago

The scalability of PHP is great, because each request is fully independent. This is like the Amazon lambda model. You /have/ to put your state in some storage back end, network attached RAM or such. This is a scalability best practice!

haimez 10y ago
Yeah, but you also have to fork a whole process per request to do it. Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request. I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.
- justinhj 10y ago
  It is easy if you are just willing to spend more money on servers. Often it's worth it.
  - haimez 10y ago
    Only if you extract a ton of value per user or can serve a huge number of users per machine. Otherwise, upping the number of servers by an order of magnitude will start requiring an operations team to maintain. That was a pretty common truism 10 years ago, but machines haven't gotten faster at the same rate lately.
  - collyw 10y ago
    Its also a problem that has been solved a long time ago and is well understood. Unlike trendy microservice architectures....
  - nrser 10y ago
    it's the "good problem". and the good problem can always be solved, though lack of reliability can seriously hurt your growth. but that doesn't mean that it's as easy as people make it out to be. i wrote and ran a big php app (Zynga's Mafia Wars). this is just about the app server (apache + php side), single-master MySQL will give you far greater problems at that scale. everyone is tearing away adding features, and the code just keeps getting bigger. everything includes everything else. so you can't just start fresh with every request, it takes way too long. so you use APC or whatever. now you have global shared state (and people start using it), but as long as no one really fucks it up that's ok. php processes are always erring and dying in weird ways that no one can figure out, especially if anyone uses the half-baked OO stuff (circa 2008-9), and tracking down obscure php state errors ranges from difficult to impossible since you're never quite sure when or where something went wrong, but it works for most people most the time, as long as you remember to clear out the error logs so they don't get big enough to crash the box. memory use still sucks at around 30M a process, meaning you can only have around 500 workers on at 16G RAM server, but it's workable. at least it's not rails. because it takes a while to talk to even Memcache (go forbid you talk to MySQL) and do all your silly user updates (games are really write-heavy) you are taking a few hundred ms per request, so 16G mem servers (it's 2008) safely top out at around 500-600 req/sec, and i think would melt close to 1000 or so. remember, your throwing everything you have at growth and features so you're not really optimizing shit. cool, just need more hardware. which is no problem. if you can get hardware. when you're co-located it takes forever to get new hardware online. not really an option. and even the F5 load balancers can only take so much. and there are issue with getting too many app servers talking to too many memcache servers. or something like that. after i left i think they saturated the data drops, which really puts you in a bind. but that's not a problem now, with cloud services, right? except that those are not limitless either. i think FarmVille ran into a wall where AWS wouldn't / couldn't supply more instances (again, this was around 2009-10 so prob a lot better now). and those are still physical machines in physical datacenters somewhere that will have all the same problems and limitations and then some. but you're going to have problems with any app runtime at that scale. and php's performance was an order-to-two or magnitude better than rails, and we never figured out how to get significantly complex and traffic-heavy java apps to stop leaking memory. though i'm sure you can. and you will! like i said, it's all solvable. hell, even MySpace didn't fail because of tech infrastructure. what i'm saying is that php wasn't (and maybe still isn't?) particularly fun when throwing hardware at it doesn't work, and you end up losing a lot of the purity / simplicity of the model because it's too damn expensive. ffs, Facebook re-wrote the runtime. that's what it took for them. and my friends there tell me it's pretty much like writing java at this point. it's a fine choice, but i'd rather not use it again. had a much better time with python before javascript ate the world.
- bartl 10y ago
  "fork" is not a major problem in PHP. In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code. That is what slows it down. It's remarkable that PHP still manages to do that in just 100ms. In Zend Framework it's slightly better because it includes an autoload option, which implies only PHP files that are actually used by athe request, get loaded. That way the overhead is "only" 50ms.
  - raarts 10y ago
    > In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code. This only proves Drupal is slow.
  - ransom1538 10y ago
    Wow. Is this comment from 2003? Uh. Why don't turn on opcache [1]? PHP7 is fast. Real fast [2]. http://php.net/manual/en/intro.opcache.php http://php.net/manual/en/intro.opcache.php https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-php-performance-benchmark-2016/ https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
    - igouy 10y ago
      > PHP7 is fast. Real fast [2]. < You need a lot more than a "Sieve of Eratosthenes" code snippet to back that up :-)
- mtberatwork 10y ago
  > Yeah, but you also have to fork a whole process per request to do it. Eh, any PHP developer worth their salt is implementing PHP-FPM. The days of forking expensive Apache processes have long been over.
  - codedokode 10y ago
    And even whey they were not over yet there was no fork for each request. A pool of workers was forked beforehand, and each worker could handle requests one by one without restarting (only PHP environment is cleared, OS level process is not restarted).
  - xorcist 10y ago
    The whole reason your Apache was (kind of) expensive to fork was PHP. You've only moved that forking to the PHP-FPM process. But that said, forking processes is not really a problem unless you do really long lived connections (such as longpoll handlers). Many other languages do that. Not many other languages have kept the CGI-like request model that PHP has, though. It encourages things like parsing code or even opening database connections on every request, unless you cache them. (Which you probably do if you are a PHP developer. But it's not always as automatic as one would hope. Have you checked your application still fits in the cache you set up?)

yxhuvud 10y ago

Managers caring about technical debt? You must live in a parallel universe. They may care about maintenance costs, but that is not really the same thing.

novaleaf 10y ago
the end result of technical debt ==> maintenance costs makes it same enough.
- GFischer 10y ago
  Looking at things from the other side: being a manager and trying to sell projects to reduce technical debt is really freaking hard in a world of short-term outlooks and revolving door of CEOs that want to improve numbers this quarter or the next, not a few years down the road.
- sqeaky 10y ago
  This is entirely true, but I have never worked with someone beyond the leader of my immediate who though the same. Most managers don't care what cruft is in there when it ships.
ddw 10y ago
They don't until things break, your app can't handle the amount of requests coming in, can't insert and fetch data in a reasonable amount of time, etc. It's at this point that shit falls apart and the manager starts to care about these technical choices and all of the time and money that will be needed to be spent to rewrite. Call it maintenance costs if you want but those costs are directly affected by the technology decisions you make.

ransom1538 10y ago

Performance? You need to update your act. PHP7 is 3x faster than python and now faster than Java 8 . The only people that can call php slow are masochistic c++ web hacks. https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-php-performance-benchmark-2016/ https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...

jbergens 10y ago
Funny that people complain about js performance. In this benchmark it was 3 times as fast as php7 and about 7 times as fast as java 8. Have not checked the details of the benchmark yet.
- juliangoldsmith 10y ago
  It's worth noting that it's compiled JavaScript vs. interpreted PHP. With something like HHVM the PHP version would likely be a lot faster.
  - secoif 10y ago
    Compiled JavaScript?
    - niutech 10y ago
      I think he meant JIT compilation.
- icedchai 10y ago
  Looks like you're reading that wrong? Java 8 is listed twice. Java 8, when using the non-standard library version of the program is second only to C++. This is pretty much as expected.
- igouy 10y ago
  > Have not checked the details of the benchmark yet. < "Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!" ;-)

riprowan 10y ago

> But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels. I'm currently maintaining an app stack for a Fortune-100 company that, if I told you what it was, you simply wouldn't believe I was telling the truth. That's how out of date it is. "Scalability, performance, technical debt and quality" never entered into it. All anyone ever cared about was "does it get the job done and what does it cost to keep it running for another year as-is?"

bmj 10y ago
I'd upvote this many time if I could. I am in the same boat--my team helps maintain a ten year old web application that is used by the largest companies in our domain. The application is literally the backbone of data used by these companies to make money. We have reliability issues, and sometimes clients get a little upset, but every year it is the same thing: how much do we need to budget for support?
TeMPOraL 10y ago
> Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels. This. In my previous job, I was literally told by my boss, that they'd consider switching from PHP to something like Ruby or whatever, but PHP programmers are cheaper so that's why they stick with it.