3 ms·

If you need to cook an egg, you can serve 1 request per second with PHP and use your CPU as heat source.

simon1ltd 5y ago
Only if your code is poorly written. Even on basic hardware, hundreds of requests per second are trivial -- assuming you aren't loading a bunch of files ("require") or making 800 trips to the database to load the site. I've never found PHPs performance to be a limiting factor, even when I was dealing with dynamic page loads coming in at sustained rates between 50 and 100 per second, and this was on PHP4/5, slow (400MHZ), single core, low ram system. FAMP stack. I assume Java apps are the same way -- I've never encountered (to my knowledge) a java-based website that wasn't slow. I assume anything that relies on a huge framework probably also had that framework to blame for most performance problems.
progforlyfe 5y ago
I prefer python or ruby, they cook the egg faster
- forgotpwd16 5y ago
  How does perl compare?
kyriakos 5y ago
Performance is the last thing one can blame php for. Its quite fast for a non compiled dynamic language and most bottlenecks are usually I/O and db access
- candiodari 5y ago
  Exactly, if there is one thing that is to blame for cooking CPU's it's an ORM, and those aren't very typical to see in PHP at all.
- seanp2k2 5y ago
  +1, once you get the right indices in place, MySQL 4.x would scale just fine to millions of rows per table. Innodb and Percona were even better. Maatkit was amazing for tuning, as was xdebug. When you just had expensive queries that were already optimized, you’d use IPVS, haproxy, apache, or RR DNS to help. This was before nginx existed. Static caching pages using Perl scripts to crawl the site and write out everything static as html files worked well too. Varnish was a real game-changer when that came out. Edit: forgot about Gearman for distributing work as well. Now people probably build the same types of things using SQS and functions. PHP was never the bottleneck, and the web could definitely “feel” faster back then on hardware an order of magnitude or two slower than we have today with these >10MiB index pages, CDNs and parallel downloads be damned.
hu3 5y ago
It's funny you say that. I was toying with PHP not long ago and managed to squeze 50k requests per second on an old server using a pure php server library called Workerman. And by squeze I mean copy 30 lines or so from their hello world tutorial and run: php start.php
- exikyut 5y ago
  I reimplemented the speedtest.net backend for fun a number of years ago, right around when it was transitioning from Flash to HTML5 and offered both. I used a PHP process running in the background using stream_socket_server(). IIRC my computer had a 5Gbps connection to localhost using HTML5, and fractionally less using Flash :> ...which meant that PHP was writing to the web browser at 5Gbps.

Only if your code is poorly written. Even on basic hardware, hundreds of requests per second are trivial -- assuming you aren't loading a bunch of files ("require") or making 800 trips to the database to load the site. I've never found PHPs performance to be a limiting factor, even when I was dealing with dynamic page loads coming in at sustained rates between 50 and 100 per second, and this was on PHP4/5, slow (400MHZ), single core, low ram system. FAMP stack. I assume Java apps are the same way -- I've never encountered (to my knowledge) a java-based website that wasn't slow. I assume anything that relies on a huge framework probably also had that framework to blame for most performance problems.

progforlyfe 5y ago

I prefer python or ruby, they cook the egg faster

forgotpwd16 5y ago
How does perl compare?

kyriakos 5y ago

Performance is the last thing one can blame php for. Its quite fast for a non compiled dynamic language and most bottlenecks are usually I/O and db access

candiodari 5y ago
Exactly, if there is one thing that is to blame for cooking CPU's it's an ORM, and those aren't very typical to see in PHP at all.
seanp2k2 5y ago
+1, once you get the right indices in place, MySQL 4.x would scale just fine to millions of rows per table. Innodb and Percona were even better. Maatkit was amazing for tuning, as was xdebug. When you just had expensive queries that were already optimized, you’d use IPVS, haproxy, apache, or RR DNS to help. This was before nginx existed. Static caching pages using Perl scripts to crawl the site and write out everything static as html files worked well too. Varnish was a real game-changer when that came out. Edit: forgot about Gearman for distributing work as well. Now people probably build the same types of things using SQS and functions. PHP was never the bottleneck, and the web could definitely “feel” faster back then on hardware an order of magnitude or two slower than we have today with these >10MiB index pages, CDNs and parallel downloads be damned.

hu3 5y ago

It's funny you say that. I was toying with PHP not long ago and managed to squeze 50k requests per second on an old server using a pure php server library called Workerman. And by squeze I mean copy 30 lines or so from their hello world tutorial and run: php start.php

exikyut 5y ago
I reimplemented the speedtest.net backend for fun a number of years ago, right around when it was transitioning from Flash to HTML5 and offered both. I used a PHP process running in the background using stream_socket_server(). IIRC my computer had a 5Gbps connection to localhost using HTML5, and fractionally less using Flash :> ...which meant that PHP was writing to the web browser at 5Gbps.