The reason why mod_php is less efficient than fastcgi php(php-fpm)

I see most answers believe mod_php is less efficient bec开发者_高级运维ause memory footprint will be higher due to serving static files,like this one.

But I have a different opinion as follows:

As a matter of fact,code section are shared among fork()ed processes,so the memory footprint predicate shouldn't hold.

The only reason I can think of is that mod_php is non-threadsafe so that web server can only create subprocesses for each request.

While in fastcgi mode web server can boost up the performance by multiplexing tricks,thus reducing the fork() overhead.

In a word,the drawback of mod_php is not its memory foot print,but the overhead of fork(),but if mod_php can be thread_safe,fork() won't be necessary and this will be the most efficient solution to serve requests.

The above is my opinion,but not 100% sure.

Is that right?

Forking is quite fast and default apache + mod_php installations also fork. (unless worker mpm is used).

The real reason is (kind of) as follows:

Standard mod_php will have reasonably big process, because the process contains contain both php and all the other apache modules, etc. If php is in a separate process, the php process can have a shorter lifetime, and quickly pass the result back to apache when PHP is done.

The other reason (as you've mentioned) is that PHP is not touched for non-php requests.

The fact that you can switch to worker mpm when using FastCGI is just bonus; but does add to the efficiency.

In general with these types of designs you'd want to always try to make both the apache and php processes as short-living as possible, and splitting them up helps.

But yea.. forks are very fast, and in certain designs they can actually operate better than Threads on Linux (no source, I just remember reading this). For webserver-type systems, I do believe Reactor-pattern based systems work even better. NGinx and Varnish are prime examples of this.