> Was this change mainly for performance?
That was one of the reasons. The biggest problem with Apache/mod_php was process memory bloating, and the way you could have a 2kb static file served by a 600M process. So you'd have to put a short recycle time on your Apache children, but still had very little control. With nginx static files get served without the leftover memory bloat from Matrix searches and massive asset listing renders.
Another reason was that nginx is designed to serve huge numbers of connections simultaneously, and with the trend toward personalisation and lots of tiny ajaxy content "bits" nginx is going to cope a lot better than Apache's prefork model.
Another benefit is the separation of the web and the application layers. This is helpful from a conceptual level when troubleshooting. And we should be able to scale in future if necessary using fastcgi nodes without requiring a web layer on those nodes, which will make scaling simpler.
Yet another is that nginx supports Lua scripting, which we may use down the track to build intelligent caching technology and intrusion prevention into the platform. But that's still a happy dream yet :)
> Who's got this in production, any down sides to it?
Lots of important sites. We've had a couple of hiccups which we've sorted out but mostly to do with tuning rather than functionality.
> Do the required PECL extensions and pear packages all seem to work with it? Especially oci/oracle
The PECL extensions and PEAR work at the PHP level. With nginx, all of that happens at the php-fpm level. One problem is that nginx doesn't do Kerb auth, so if you need to use Kerb (AD SSO eg) you're still going to need Apache in your stack at this stage.
> Is there a sample config like we used to have for apache available? That was great
I've had a hunt around our public documentation but haven't seen any. You could probably sneak a peek under the hood of the vm to get more information.