[davidw]

What's "problematic" about mod_php? It's got to be one of the more widely used bits of software out there. Like anything, I'm sure there are tradeoffs involved, but perhaps it's better to be a bit more explicit about what they are rather than stopping at "problematic"?

[jolan]

I've had a couple problems but I wouldn't call it problematic:

1) When you select mod_php/the Apache SAPI, certain functions get disabled like chroot() and pcntl_fork() since they're not safe to be used under Apache. This is annoying when you have some backend scripts that need those functions.

2) If you run PHP with all the popular plugins, you're looking at about 15MB per Apache process/thread. @256 active clients that's almost 4GB of RAM. Insane, especially considering it's loaded in memory whether or not the requested resource is PHP or not.

I recently switched to Nginx+FastCGI and I'm very happy with the speed and memory usage. FPM makes it even better.

[jonhohle]

For 2, wouldn't most of that memory be either COW or physically shared, read-only? It's been about a year and a half since I've operated a large PHP site, but I don't recall the apache workers getting anywhere close to 15MB each, unless a request was operating on a larger than normal dataset. (this site used curl, gd, memcache, uuid, pspell, tidy, soap, and probably some others I've forgotten, loaded dynamically.)

[davidw]

How much memory does each FCGI process take up, just out of curiosity? You still need 256 of them to deal with that many concurrent connections.

[jolan]

I run bare php FCGI processes that use 4.5MB of memory and use dl() to load the extra libs on demand now.