Except php is the short bus of programming languages, so having it run fast doesn't really interest me. PHP gets to make optimizations that perl doesn't, like storing pointers directly to the functions instead of looking them up from a symbol table, but then that also ties your hands when you want to do things like override a function or wrap it with a method modifier, which are easy in perl and impossible in php. If there was any one language I wish I could eliminate from my life, it would be php, but wordpress/drupal popularity makes that hard. It's even faster these days because Facebook pours money into it; its a shame the r&d doesn't go toward a more deserving language.
I feel like there is something going wrong with the "accept" loops in Gazelle. I checked on the implementation, and it looks very much like it forks, and then each worker calls accept() on the same listening socket, and then they *should* be able to receive new connections in parallel. Yet, on the slower server, the pool of workers were unable to beat the performance of a single worker. I'm aware of the "stampede" effect where a listen socket becoming readable wakes all the workers instead of just one, but with Gazelle's loop implemented in C, that should still be low enough overhead that they should be able to run in parallel even for a tiny request. I'd be interested to see it if you or anyone else decide to chase this down to some microsecond-level traces. It's a lot of effort though, to shave off a mere 3-5ms per request. It wouldn't make any difference to any of the apps I maintain. | [reply] |
