3 ms·

> nowadays its a solid choice for backend stuff Hell no. PHP is awful for background processing. I do DevOps for a bunch of different languages (Node.js, Elixi

by mikl 3y ago

> nowadays its a solid choice for backend stuff Hell no. PHP is awful for background processing. I do DevOps for a bunch of different languages (Node.js, Elixir, PHP, Java) and PHP is always the problem child. Poor concurrency, memory leaks, general RAM bloat, etc.

gumballindie 3y ago
Memory leaks in PHP? Poor concurrency? Thats new. However what you describe is more of a developer skill problem. Although i’d use other languages for background processing - ie python or nodejs PHP can be pretty solid too but you know, use the right tool for the task at hand. Being religious about a language is a symptom of poor engineering skills - common in the php world, where they tend to use it for everything.
- mikl 3y ago
  “developer skill problem”. Nice insult there, I’m tempted to respond in kind, but I’ll just point out that PHP doesn’t have much support for async operations of any kind, and all the big frameworks are written in single-threaded “blocking” fashion, so the only way to have parallel processing is to run multiple instances of the program in parallel. And if you google for “php memory leak”, you’ll get a lot more than 0 results.
  - gumballindie 3y ago
    Sorry for making it sound as an insult, i should have phrased it differently. Since php scripts are meant to be run once per request memory leaks are not an issue - any build up gets “reset” once execution ends. There are however shit frameworks that have circular references to objects and do all kinds of crap that builds memory up - easily avoided by parallel queue consumers. Threading and async are non issues given my statement above, hence me blaming on the dev’s skill and not understanding what the language does. For instance, you dont normally start a background process with an event loop to handle stuff. You start queue consumers at set intervals that run in parallel, or scripts that process batches of code - thus mimicking parallelism in a classic multi threaded app. This way you reduce the blast radius, are guaranteed that at least some data will always be processed and avoid memory leaks alltogether. No need for “conscious” async since its async by nature. However there is nuance in everything. Would you be able to provide a specific example of where you end up with such issues so i can better detail an example of how i would approach it?
    - mikl 3y ago
      > php scripts are meant to be run once per request memory leaks are not an issue Yes, and that’s exactly why I said that PHP is awful for background processing, because there the process ideally runs continuously, or at least as long as there’s data to process. With PHP, I have to continuously re-spawn the processes to keep the memory leaks in check. If your application is so simple that it doesn’t need to process data outside of the request/response cycle, I’m sure PHP is fine. And sure, you can compensate for PHPs lack of async processing by spawning more processes, but that makes the RAM bloat problem even worse.
      - trog 3y ago
        We have scripts that have been running continuously for probably years at a time with none of these issues. The only time they stop is when servers are rebooted for updates. We actually had a big argument about building them like this for exactly the reasons you mentioned though - the preference for me and some others was to run them as once off's from cron, specifically to avoid the possibility of memory issues. Our tech lead wanted them to run as services (I think to improve responsiveness primarily). I didn't think it would work as well, but history has proven that it worked fine. I can't say it was better - it took a while to work out the kinks - but these things have been happily running for over a decade with basically zero issues relating to memory leaks, etc. They're not super complicated but not trivial either.
danaris 3y ago
They didn't say "background processing". They said "backend stuff"—ie, the code that runs on the server that does the processing for stuff the client submits, as opposed to "frontend stuff," which runs on the client itself. PHP isn't great for persistent background processing because that's not what it's designed for, any more than Python is good as a frontend DOM manipulation language.
- gumballindie 3y ago
  However php can be used for background processing if done right - but its speed in processing large amounts of data is dogshit. For instance if you wish to iterate massive arrays in one go then python is waaay better. If you wish to iterate each one at a time then that can easily be done via queues and can be parallelised endlessly quite easily. But one common issue with php devs is that they are religious about the language. Probably because they dont actually understand programming as a whole - not even php itself. They should use the best tool for the task at hand and not be religious about php. I remember when i was in that dark place i even considered php for gui apps lmao because php was hot hot hot.
  - trog 3y ago
    There is (almost) /always/ a faster language. As with any stack, the advantage of PHP being used for background processing in a PHP application is you're already using it, so you don't end up having to manage multiple codebases. I was involved in several large PHP projects which did a lot of background processing (not Google scale, but telco scale) and performance was more than adequate in all cases. The advantages of running a single codebases far outweighed any potential benefit of a speed increase from switching to another language. (... I say that having been the jerk that actually did rewrite one small component in C and it turned out to be a huge waste of time and effort and just meant something additional the team has had to manage in the almost 20 years since I did it!)
    - gumballindie 3y ago
      Well ok but it seems like the C app you “wasted time” on lasted 20 years. I bet the rest of that stack either moved away from php or added extra languages. But yes, the reluctance to use other languages and different codebases was also a common argument in all php teams i worked with. People need to understand that a language is a tool not a religion. If using php for the web layer, python for processing background tasks and nodejs for apis makes sense then do so by all means. PHP devs need to understand that. The PHP apps i built were for large userbases processing billions of pounds and in one case dollars a year. The language if used right is superb. It’s the type of dev using it that’s usually not, I am sorry to say that.

by mikl 3y ago

gumballindie 3y ago

Memory leaks in PHP? Poor concurrency? Thats new. However what you describe is more of a developer skill problem. Although i’d use other languages for background processing - ie python or nodejs PHP can be pretty solid too but you know, use the right tool for the task at hand. Being religious about a language is a symptom of poor engineering skills - common in the php world, where they tend to use it for everything.

mikl 3y ago
“developer skill problem”. Nice insult there, I’m tempted to respond in kind, but I’ll just point out that PHP doesn’t have much support for async operations of any kind, and all the big frameworks are written in single-threaded “blocking” fashion, so the only way to have parallel processing is to run multiple instances of the program in parallel. And if you google for “php memory leak”, you’ll get a lot more than 0 results.
- gumballindie 3y ago
  Sorry for making it sound as an insult, i should have phrased it differently. Since php scripts are meant to be run once per request memory leaks are not an issue - any build up gets “reset” once execution ends. There are however shit frameworks that have circular references to objects and do all kinds of crap that builds memory up - easily avoided by parallel queue consumers. Threading and async are non issues given my statement above, hence me blaming on the dev’s skill and not understanding what the language does. For instance, you dont normally start a background process with an event loop to handle stuff. You start queue consumers at set intervals that run in parallel, or scripts that process batches of code - thus mimicking parallelism in a classic multi threaded app. This way you reduce the blast radius, are guaranteed that at least some data will always be processed and avoid memory leaks alltogether. No need for “conscious” async since its async by nature. However there is nuance in everything. Would you be able to provide a specific example of where you end up with such issues so i can better detail an example of how i would approach it?
  - mikl 3y ago
    > php scripts are meant to be run once per request memory leaks are not an issue Yes, and that’s exactly why I said that PHP is awful for background processing, because there the process ideally runs continuously, or at least as long as there’s data to process. With PHP, I have to continuously re-spawn the processes to keep the memory leaks in check. If your application is so simple that it doesn’t need to process data outside of the request/response cycle, I’m sure PHP is fine. And sure, you can compensate for PHPs lack of async processing by spawning more processes, but that makes the RAM bloat problem even worse.
    - trog 3y ago
      We have scripts that have been running continuously for probably years at a time with none of these issues. The only time they stop is when servers are rebooted for updates. We actually had a big argument about building them like this for exactly the reasons you mentioned though - the preference for me and some others was to run them as once off's from cron, specifically to avoid the possibility of memory issues. Our tech lead wanted them to run as services (I think to improve responsiveness primarily). I didn't think it would work as well, but history has proven that it worked fine. I can't say it was better - it took a while to work out the kinks - but these things have been happily running for over a decade with basically zero issues relating to memory leaks, etc. They're not super complicated but not trivial either.

danaris 3y ago

They didn't say "background processing". They said "backend stuff"—ie, the code that runs on the server that does the processing for stuff the client submits, as opposed to "frontend stuff," which runs on the client itself. PHP isn't great for persistent background processing because that's not what it's designed for, any more than Python is good as a frontend DOM manipulation language.

gumballindie 3y ago
However php can be used for background processing if done right - but its speed in processing large amounts of data is dogshit. For instance if you wish to iterate massive arrays in one go then python is waaay better. If you wish to iterate each one at a time then that can easily be done via queues and can be parallelised endlessly quite easily. But one common issue with php devs is that they are religious about the language. Probably because they dont actually understand programming as a whole - not even php itself. They should use the best tool for the task at hand and not be religious about php. I remember when i was in that dark place i even considered php for gui apps lmao because php was hot hot hot.
- trog 3y ago
  There is (almost) /always/ a faster language. As with any stack, the advantage of PHP being used for background processing in a PHP application is you're already using it, so you don't end up having to manage multiple codebases. I was involved in several large PHP projects which did a lot of background processing (not Google scale, but telco scale) and performance was more than adequate in all cases. The advantages of running a single codebases far outweighed any potential benefit of a speed increase from switching to another language. (... I say that having been the jerk that actually did rewrite one small component in C and it turned out to be a huge waste of time and effort and just meant something additional the team has had to manage in the almost 20 years since I did it!)
  - gumballindie 3y ago
    Well ok but it seems like the C app you “wasted time” on lasted 20 years. I bet the rest of that stack either moved away from php or added extra languages. But yes, the reluctance to use other languages and different codebases was also a common argument in all php teams i worked with. People need to understand that a language is a tool not a religion. If using php for the web layer, python for processing background tasks and nodejs for apis makes sense then do so by all means. PHP devs need to understand that. The PHP apps i built were for large userbases processing billions of pounds and in one case dollars a year. The language if used right is superb. It’s the type of dev using it that’s usually not, I am sorry to say that.