7 ms·

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 b

by 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.
    - dakull 10y ago
      >php's performance was an order-to-two or magnitude better than rails Again PHP (the language) vs. Rails (the framework). What framework was that `big php app` using?
      - chriswarbo 10y ago
        > What framework was that `big php app` using? PHP is a framework. True it's not a particularly nice one, and some people build even more layers on top, but it comes with all manner of HTTP/url/DB/etc. stuff out of the box. It's also a templating language (that's what the "<?php" tags are for); although, again, not particularly great, and some people layer more abstractions on top.
        brightball 10y ago
        Very true. It's basically an interface to a C framework.
        bigtunacan 10y ago
        In the sense of comparing PHP and Rails, then no PHP is not a framework. Codeignitor, Laraval, Cake, Yii; those are PHP frameworks and fair comparisons to Rails. I can (and have) just grabbed Rack and rolled most everything myself in Ruby and it has way less overhead and is much more performant than Rails. Ruby also has it's own templating language; ERB is part of Ruby core. So comparing PHP to Rails is a bit apples and oranges.
        nrser 10y ago
        it's a business decision comparison, not a technical categorical comparison. you need something to receive http request and return http responses, and you're comparing different popular (because hiring, training, and available community / support resources) ways to do that. they might be apples and oranges but at that level you're concerned with comparing fruits.
        10y ago
- 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?)

by jwatte 10y ago

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.
  - dakull 10y ago
    >php's performance was an order-to-two or magnitude better than rails Again PHP (the language) vs. Rails (the framework). What framework was that `big php app` using?
    - chriswarbo 10y ago
      > What framework was that `big php app` using? PHP is a framework. True it's not a particularly nice one, and some people build even more layers on top, but it comes with all manner of HTTP/url/DB/etc. stuff out of the box. It's also a templating language (that's what the "<?php" tags are for); although, again, not particularly great, and some people layer more abstractions on top.
      - brightball 10y ago
        Very true. It's basically an interface to a C framework.
      - bigtunacan 10y ago
        In the sense of comparing PHP and Rails, then no PHP is not a framework. Codeignitor, Laraval, Cake, Yii; those are PHP frameworks and fair comparisons to Rails. I can (and have) just grabbed Rack and rolled most everything myself in Ruby and it has way less overhead and is much more performant than Rails. Ruby also has it's own templating language; ERB is part of Ruby core. So comparing PHP to Rails is a bit apples and oranges.
        nrser 10y ago
        it's a business decision comparison, not a technical categorical comparison. you need something to receive http request and return http responses, and you're comparing different popular (because hiring, training, and available community / support resources) ways to do that. they might be apples and oranges but at that level you're concerned with comparing fruits.
        10y ago
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?)