Re:Handling server load for the Raspberry Pi Zero launch
by nickpsecurity on Monday November 30, 2015 @02:22PM
(#10651145)
"I would not consider this an advantage per se, because exactly like C, it's difficult to find a certain type of programmer who cares about things like performance or has a real understanding of what is happening when their code executes."
I agree. It's one of the few things about PHP that you see in both lists of advantages and drawbacks haha.
"As far as your points 1, 4, 6, and 7 are concerned - it's pretty much on par with other dynamic languages such as Lua or Ruby."
I believe it for 1, 4, and 7 but am skeptical on 6: internal quality and security. The few times I saw people dedicate time to PHP vulnerabilities were finding them 10+ at a time. Lua and Go should do better due to simplicity but I haven't verified that. Coverity reported Python having lowest defect rate of about anything at one point. Getting updates on scoring like that vs other dynamic and static languages might be a useful metric. Compared to most web stuff, I'll leave 6 at maybe.
"Rubyists tend to talk about how speed is not important, which I disagree with, and PHP has never let me down in this regard."
They're foolish if so. Definitely a speed advantage for PHP given work (esp Facebook's) put into that.
"Personally, I think PHP is strongest in fact without using the class system religiously, and instead making major use of its array/list type and functional code patterns."
I believe that. It was true for some other languages before. So, that solves 2 but 3 is still on table. Languages supporting strong static analysis, design-by-contract, advanced typing, and so on can do better than a PHP-like language. This includes dynamic ones extended with that stuff. So, 3 is a maybe leaning towards no if against application rather than scripting languages.
" PHP's unique strength and primary reason for me using it is its execution model in a web server environment. Every other language and web framework has gone the way of the application server, but PHP is using a per-request execution model which is incredibly powerful if used right."
"In exchange for this you get to benefit from a stateless app. If your code, the interpreter, or a library screws up, you're not taking down the server with it, you just disrupt the requests that actually hit the bug."
Definitely makes things easier to understand and reduces issues. Certainly an advantage against anything not supporting such a model where it's needed. Adds support on 5 given stateless reliability is easier to boost.
" there are lots of things this is unsuitable for, especially when you really do need a persistent app server. "
That's a lot of modern web apps, though, right? I can't guess at the percentage but "LAMP stack" implies databases and persistence are the norm.
" it can be advantageous to write a small broker-style server in C or Node (or Go, or Erlang, whatever you want), and put the intelligence part in a PHP backend API."
Smart idea. I can see the potential gains. There's parallels in highly assured systems where we kernelize critical functionality, implement it robustly, and untrusted stuff just calls it often with interface checks. It's a proven method with lots of application. Do you have any resources on doing this right in web applications out of curiosity? Just in case I have to get back into that.
Conclusion
We started with 7 metrics. Your case showed it's roughly comparable to competition in 4/7, probably better on 1/7, a maybe on 1/7, and a stronger maybe (stateless) on 1/7. Rather than horrible, with these metrics it comes out as OK in most ways with advantages in some and potential disadvantages in just a few. So, baring new data or metrics, it's objectively Ok at this point compared to others with possible advantages in speed or error minimization at component level. I say possible because I've seen competitors do similar things. I'd do case by case comparisons there but PHP is overall OK based on your data.
I agree. It's one of the few things about PHP that you see in both lists of advantages and drawbacks haha.
"As far as your points 1, 4, 6, and 7 are concerned - it's pretty much on par with other dynamic languages such as Lua or Ruby."
I believe it for 1, 4, and 7 but am skeptical on 6: internal quality and security. The few times I saw people dedicate time to PHP vulnerabilities were finding them 10+ at a time. Lua and Go should do better due to simplicity but I haven't verified that. Coverity reported Python having lowest defect rate of about anything at one point. Getting updates on scoring like that vs other dynamic and static languages might be a useful metric. Compared to most web stuff, I'll leave 6 at maybe.
"Rubyists tend to talk about how speed is not important, which I disagree with, and PHP has never let me down in this regard."
They're foolish if so. Definitely a speed advantage for PHP given work (esp Facebook's) put into that.
"Personally, I think PHP is strongest in fact without using the class system religiously, and instead making major use of its array/list type and functional code patterns."
I believe that. It was true for some other languages before. So, that solves 2 but 3 is still on table. Languages supporting strong static analysis, design-by-contract, advanced typing, and so on can do better than a PHP-like language. This includes dynamic ones extended with that stuff. So, 3 is a maybe leaning towards no if against application rather than scripting languages.
" PHP's unique strength and primary reason for me using it is its execution model in a web server environment. Every other language and web framework has gone the way of the application server, but PHP is using a per-request execution model which is incredibly powerful if used right."
"In exchange for this you get to benefit from a stateless app. If your code, the interpreter, or a library screws up, you're not taking down the server with it, you just disrupt the requests that actually hit the bug."
Definitely makes things easier to understand and reduces issues. Certainly an advantage against anything not supporting such a model where it's needed. Adds support on 5 given stateless reliability is easier to boost.
" there are lots of things this is unsuitable for, especially when you really do need a persistent app server. "
That's a lot of modern web apps, though, right? I can't guess at the percentage but "LAMP stack" implies databases and persistence are the norm.
" it can be advantageous to write a small broker-style server in C or Node (or Go, or Erlang, whatever you want), and put the intelligence part in a PHP backend API."
Smart idea. I can see the potential gains. There's parallels in highly assured systems where we kernelize critical functionality, implement it robustly, and untrusted stuff just calls it often with interface checks. It's a proven method with lots of application. Do you have any resources on doing this right in web applications out of curiosity? Just in case I have to get back into that.
Conclusion
We started with 7 metrics. Your case showed it's roughly comparable to competition in 4/7, probably better on 1/7, a maybe on 1/7, and a stronger maybe (stateless) on 1/7. Rather than horrible, with these metrics it comes out as OK in most ways with advantages in some and potential disadvantages in just a few. So, baring new data or metrics, it's objectively Ok at this point compared to others with possible advantages in speed or error minimization at component level. I say possible because I've seen competitors do similar things. I'd do case by case comparisons there but PHP is overall OK based on your data.