On Fri, Feb 01, 2002 at 09:14:24AM -0800, Rasmus Lerdorf wrote: > > a) if Apache 2 is a single-process server (as opposed to Apache 1.x which > > forks a new process for a new request) > > It is a hybrid server which can be anything from one to the other. > > > b) if PHP will work, or does work, with Apache 2 in this mode > > It works today. > > > c) how database connection pooling will work with a single http/php > > multithreaded server process > > There is no database pooling. Then how does pg_pconnect() work, for instance, when there's only a single process that talks to the database? With persistent connections, as they work now, you can have as many database connections per apache child as you have databases hosted on your box. On our in-house server (which is typically not very busy) it looks like this at the moment: ---------------------- snip ---------------------- frank@limedes:~ > ps ax |grep postgres 17954 ? S 0:09 postgres: wwwrun archi 127.0.0.1 idle 20479 ? S 0:00 postgres: wwwrun ip_adressen [local] idle 21576 ? S 0:12 postgres: wwwrun archi 127.0.0.1 idle 21707 ? S 0:00 postgres: nobody crewscout 192.168.100.220 idle 21736 ? S 0:00 postgres: nobody archimeta 192.168.100.220 idle 21737 ? S 0:00 postgres: nobody archimeta 192.168.100.220 idle 21738 ? S 0:00 postgres: nobody archimeta 192.168.100.220 idle 21739 ? S 0:00 postgres: nobody crewscout 192.168.100.220 idle 21740 ? S 0:00 postgres: nobody crewscout 192.168.100.220 idle 21777 ? S 0:00 postgres: nobody crewscout 192.168.100.220 idle 21844 ? S 0:00 postgres: nobody archimeta 192.168.100.220 idle 21845 ? S 0:00 postgres: nobody archimeta 192.168.100.220 idle 21846 ? S 0:00 postgres: nobody archimeta 192.168.100.220 idle ---------------------- snap ---------------------- Which is not a problem at all. However, things start to get awkward when the system gets busier: Say you have 20 apache children sitting around waiting for clients, and each one of them has at some stage in their career been asked to talk to each of the 5 databases using persistent connections that are hosted on this box. This means you'd have 100 postgres processes sitting around, where most of them would be idle . . . > > > d) if maybe integrating php with a servlet engine as described in > > > > http://www.php.net/manual/en/ref.java.php > > > > allows you to use connection pooling via jdbc or something . . . ? > > Sure. Gotta look into it, then! :) > > > I am asking because connection pooling as it works now with persistent > > connections is pretty awkward, and leads me to look with envy on the > > Aolserver/TCL crowd . . . (I like PHP and see no reason to switch to TCL > > except for the connection pooling issue). > > Why do you think you need connection pooling? Having contention for a > small set of connections is certainly not going to speed anything up. Is Compared to persistent connections, there would be no speedup; compared to non-persistent connections, yes there would - because with a connection pool you don't incur the overhead of establishing a new connection for every request, basically as with persistent connections. > it because you have license issues and are only allowed a limited number > of concurrent connections? No, licensing is not an issue. I use persistent connections to offset the overhead of creating a db connection in the first place, which is considered hefty if you have simple queries (it matters less with more expensive sql queries). Persistent connections are awkward because you need to configure your database server to accept the number of simultaneous connections that you actually need many times over, which is not exactly resource-friendly and may bog down a busy server. Then there's the added complication with transacations that is listed amongst the caveats with persistent connections at http://www.php3.de/manual/en/features.persistent-connections.php The transaction issue supposedly does not arise with a single-process/multithreaded/connection pooling server, presumably (never wrote any pooling code myself . . . ) because it stems from the fact that with a multiprocess server, you don't know which process will answer the next request. [ . . . ] > There are also other options in the works for this problem. The SRM > project addresses this Interesting . . . ! Regards, Frank
