Comments on: PHP And pg_connect: Post Mortem http://blog.charcoalphile.com/2008/02/24/php-and-pg_connect-post-mortem/ On Databases, Recovery, Tech Thu, 09 Sep 2010 08:23:31 +0000 http://wordpress.org/?v=2.2.1 By: admin http://blog.charcoalphile.com/2008/02/24/php-and-pg_connect-post-mortem/#comment-167 admin Mon, 10 Mar 2008 21:38:52 +0000 http://blog.charcoalphile.com/2008/02/24/php-and-pg_connect-post-mortem/#comment-167 Yeah, connecting through /var/lib/postgresql has half the overhead of 127.0.0.1, but you would either have to setup an ident user or reconfigure pg_hba.conf. I'm starting to think the reason Python was so much faster is because PostgreSQL was running out of connections. After giving pgpool a hard limit of 90 to the maximum number of open connections, performance of the Python script dropped significantly, to ~300 requests a second (still faster than PHP). It may just be that my setup isn't up to par in order to test it, since there really shouldn't be too many open connections with a concurrency of ten. I'll have to give it a shot on a Core 2 Duo, when I get some time. I know all about the evils of persistent connections. Even with a very small number of users, you can easily run out of connections. Since connections are kept open per-apache-process, and not pooled across all Apache processes like many believe, benchmarks should be taken with a grain of salt, as persistent connections work in favor of the benchmark. Yeah, connecting through /var/lib/postgresql has half the overhead of 127.0.0.1, but you would either have to setup an ident user or reconfigure pg_hba.conf.

I’m starting to think the reason Python was so much faster is because PostgreSQL was running out of connections. After giving pgpool a hard limit of 90 to the maximum number of open connections, performance of the Python script dropped significantly, to ~300 requests a second (still faster than PHP). It may just be that my setup isn’t up to par in order to test it, since there really shouldn’t be too many open connections with a concurrency of ten. I’ll have to give it a shot on a Core 2 Duo, when I get some time.

I know all about the evils of persistent connections. Even with a very small number of users, you can easily run out of connections. Since connections are kept open per-apache-process, and not pooled across all Apache processes like many believe, benchmarks should be taken with a grain of salt, as persistent connections work in favor of the benchmark.

]]> By: Ian Eure http://blog.charcoalphile.com/2008/02/24/php-and-pg_connect-post-mortem/#comment-159 Ian Eure Fri, 07 Mar 2008 21:18:08 +0000 http://blog.charcoalphile.com/2008/02/24/php-and-pg_connect-post-mortem/#comment-159 Persistent connections should be avoided at all costs. Because the connections are held open after they're not needed, the DB server ends up with a much larger number of connections, and (at least with MySQL) will start refusing them when it hits it's limit. You might try experimenting with other authentication methods on the DB server to speed up the pg_connect() call. The PHP function is a very thin wrapper around the PostgreSQL library's pg_connect(), so there shouldn't be much difference between PHP and any other binding. Perhaps PyDB is lazy-connecting, or shuffling that latency in some other way? I'd be interested to see how the PHP pg_connect() compares with C. Oh, and if you're connecting to a name (db.foo.com) vs an IP, change. DNS lookups could be slowing things down. You could also try connecting via a socket instead of TCP/IP. Persistent connections should be avoided at all costs. Because the connections are held open after they’re not needed, the DB server ends up with a much larger number of connections, and (at least with MySQL) will start refusing them when it hits it’s limit.

You might try experimenting with other authentication methods on the DB server to speed up the pg_connect() call. The PHP function is a very thin wrapper around the PostgreSQL library’s pg_connect(), so there shouldn’t be much difference between PHP and any other binding. Perhaps PyDB is lazy-connecting, or shuffling that latency in some other way?

I’d be interested to see how the PHP pg_connect() compares with C.

Oh, and if you’re connecting to a name (db.foo.com) vs an IP, change. DNS lookups could be slowing things down. You could also try connecting via a socket instead of TCP/IP.

]]>