mod_fast_apache, FastCGI, and mysqli View as Markdown

steve wrote:

Oh, and allow persistent connections in db apis again (like mysqli).

It might happen. Wez Furlong was contemplating a persistent
connection implementation for the generic PDO interface following
on from the persistent connection model in the oci8 extension for
Oracle.

As an example, lets suppose an example with 2000 connections, using
keep-alive, with 20 connections downloading static content and 50
downloading dynamic (PHP) content. In Apache 1.3, you would have to
accommodate 2000 processes (either changing the hard limit, or using
multiple servers). If you used persistent connections that would be
2000 (almost all idle) connections to mysql. (In the real world this
is why you would either disable persistent connections or keep-alive,
and most likely both.)

The oci8 extension lets you timeout idle persistent connections.

Unrelated to your FastCGI suggestion but FYI on database connection
pooling: http://blogs.oracle.com/opal/2007/01/03. The pooling
described has no dependency on how you deploy your application and
works across multiple application types connecting to the DB.

Chris

--
Christopher Jones, Oracle
Email: Christopher.Jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/

A couple of points. mysqli doesn't have persistent connections because
the authors of that particular extension don't think it is a good idea.
It's not a PHP-wide thing, PDO and others do have it.

If you are going to FastCGI for performance and scalability reasons
because you don't want a heavyweight web server process handle a dynamic
request, then you are essentially just using the web server as a proxy
which isn't really what it was written to be. There are much more
effective reverse proxies out there that can do that.

The best reason for FastCGI, and why you won't find anyone saying it is
a bad thing to support, is for shared hosting services to better
separate users in system-level jails.

Let's not get carried away and make it out to be the solution to
everything, because it certainly isn't. The larger companies have
Akamai or Akamai-like solutions for all their static file needs, and
most of the smaller ones have thttpd or lighhttpd lightweight servers
handling those or they have stuck Squid or Pound out in front. For
these sorts of architectures the extra handoff to a FastCGI process
doesn't make much sense because every request that gets through to the
web server is going to be a dynamic one so Apache1 or Apache2-prefork is
managing these process-based PHP interpreters in exactly the same
fashion that FastCGI would with the exception that you have more control
with the richness of Apache and you are closer to the actual request and
can make use of the rich set of Apache modules out there.

So yes, for the ISP case, I am all for suggesting that FastCGI should be
the default way to run PHP. We've been saying that for a while
actually. But in other cases you are going to have a much harder time
convincing me. And I actually know a little bit about running PHP in
extremely high-traffic situations.

-Rasmus

steve wrote:

From my experience with PHP over the years, in setups with both low
and high traffic, I'd like to humbly put out a suggestion: have PHP
include its own FastCGI SAPI in PHP 5.x and make it the
default/recommended in PHP 6. Oh, and allow persistent connections in
db apis again (like mysqli).

The current FastCGI implementation for Apache has not changed in years
(it actually won't compile on the Apache Group's recommended 2.2
version of Apache without end user tweaks). The code is there and it
works, though I'm not sure of license compatibility. Though someone
must know the protocol well since the PHP side of things was rewritten
not long ago.

Here are some of the benefits (and some rehash of things for the
benefit of people finding this post via Google, et al):

1. FastCGI can be found across almost all web servers, and it factors
   out the whole threading issue. Threaded web servers can be a great
   benefit (and the event MPM in Apache 2.2 is a boon to using keep-alive
   efficiently).

2. In a process based webserver with PHP "builtin" as a module, every
   request has the whole php engine there -- even if it is not used (say
   a static image request, or just hanging around because of a keep-alive
   request). Each of those processes each hold to their "persistent"
   connections for, say, mysql. Which is why its such a bad thing -- all
   these processes holding open connections even if they aren't going to
   use them (like the image or keep-alive connection). Its around this
   point that we start thinking about connection pooling even though that
   is not needed.

As an example, lets suppose an example with 2000 connections, using
keep-alive, with 20 connections downloading static content and 50
downloading dynamic (PHP) content. In Apache 1.3, you would have to
accommodate 2000 processes (either changing the hard limit, or using
multiple servers). If you used persistent connections that would be
2000 (almost all idle) connections to mysql. (In the real world this
is why you would either disable persistent connections or keep-alive,
and most likely both.)

Now in a Apache 2.0 and FastCGI context (out the hat, say 200 threads
per process) we would have 10 processes to split the 2000 threads.
Lets say you were wonderful at guessing the size of the PHP FastCGI
pool and put it at 50 (same as the number of dynamic requests at this
moment in time). You would have 50 connections to mysql as well
(moving to fast-cgi really helped here!).

In Apache 2.2 with event MPM, we would have one process and 200
threads (with only 71 being in active use). Same PHP process count as
Apache 2.0 and same connection count to MySQL.

Notice that the PHP FastCGI pool is acting as connection pooling
rather effectively for persistent connections. You might have turned
that off before, but now you can turn it on and see some return.

3. mysqli: OK, other than the fact that the FastCGI doesn't come
   preinstalled with either Apache or PHP, and you might have to tweak it
   to compile for Apache 2.2, you can do the above already today. So why
   this note? Well, if PHP told everyone via the manual and by
   integrating a fastcgi module (say mod_fast_apache, mod_fast_apache2,
   etc), then there likely (ok, hopefully) would have been some positive
   side effects. Like mysqli having persistent connections. I'm guessing
   they aren't there because people wanted to protect users from using
   them with a process based webserver like Apache1.3. "Dumb users, it
   doesn't help them, only makes it worse". Yes, true, assuming people
   using mod_apache. Change the assumption, and maybe different things
   happen. Hmm, this is a lot to write when I could have said "give us
   back persistent connections!"...

4. Setting up FastCGI is horrible/ugly. Creating a fastcgi module for
   apache that only deals with PHP on the other end, gives a bit of
   leeway on how to do configuration stuff. Perhaps make FastCGi-PHP as
   easy to config as mod_apache. Thus calling it mod_fast_apache. People
   will be drawn to the word fast, btw.... :p

5. FastCGI is a far better base from which to deal with security for
   PHP, even if not addressed by PHP. Jails, having different processes
   for different users, etc. The latter doesn't interest me at all, but
   the former does. It need not be a security play, but it would give a
   better base from which to start. Well, my opinion, anyway.

6. I preface this with "I don't know what I'm talking about" here: is
   all the thread safe code in php really necessary? My experience is
   that FastCGI is both more stable and faster. Is php used in embedded
   threaded environments? Or was the the threading just for use on
   Windows, where we can better use FastCGI? Is there something to be
   gained by removing it?

OMG, am I still writing?

Somewhat off topic: Having the webserver and php run on the same
machine is rather a poor mans way of scaling. Does anyone have stats
on how well chained processing compares? (Like separating the web
server and the PHP onto separate machines, or setup with a proxy
server that directs traffic to an apache 1.3 server just for dynamic
pages (very similar to the previous split but using http protocol
instead of the fastcgi protocol, or using both approaches)???

OK, thanks for listening to my suggestion. Here is the short version:

a) copy the fastcgi apache module to php's source
b) make the config options easy for the basic user
c) included in future distributions
d) make default at a later point
e) bring back persistent connections
f) remove thread safe code??? maybe crazy idea

-steve