If you need to cook an egg, you can serve 1 request per second with PHP and use your CPU as heat source.
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.
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.
And by squeze I mean copy 30 lines or so from their hello world tutorial and run: php start.php
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.