Okay, so it sounds like I was right then after all if you're conflating curl hacks which require the spawning of a completely different process and a full blown TCP connection to achieve anything with an actual proper threading solution or async IO implementation (FWIW I find it amusing that you claim multithreading and async IO are completely unrelated things and then pretend curl is an async IO implementation- facepalm. You don't even know how PHP's curl library works).
I was going to reply in a bit more detail to everything in between, but then I got to this section of your post and realised it's fruitless as you don't even understand the basics:
"You're still going to spend 90% of your time waiting on blocking io. you can't complete your request until that io request is done, sure if i have 30ms of php code executing and a 180ms sql query I can use asynchronous io to make that entire request take 180ms instead of 210ms, but you're still spending the bulk of your time waiting for that 180ms sql query."
There's two problems with this:
1) You still demonstrate that your knowledge doesn't stretch beyond basic CRUD environments, you believe that everything you do on the web is simplistic web front-end, database backend CRUD type stuff. This is false, and if you had any worthwhile professional experience you'd know that a lot more typically goes on behind the scenes than my first website type setups (but that's probably also why you think PHP is acceptable, because you're not doing anything that matters).
2) On one hand you're talking about high throughput environments, and on the other you're talking about a process only handling one client at a time, which is what I was referring to when I talked about the PHP way. In more professional environments you don't need a whole new process for each concurrent request. That's a massive amount of unnecessary overhead, and environments like .NET and Java allow you to simply process other incoming requests in the same process whilst one is awaiting IO.
You seem to completely lack any grasp of the cost of firing up processes, as you seem to believe that spawning a process is an equivalently performant thing to do as firing off a new thread. It's sad, and you just prove my point that PHP folks only support PHP so vehemently because they don't know any better.