note 10610 deleted from features.persistent-connections by jimw

Update - it was brought to my attention that the script should actually do something with the db connection. so, after the pg_(p)connect statement, try throwing in a pg_exec and a pg_result. This lowers your benchmark results a bit. However, consider this, with hypothetical numbers: Plain old postgre connection: 2 seconds "Select * ... " query: 2 seconds Persistent postgre connection: 1 second "Select * ... " query on persistent connection: 2 seconds (I would assume) So the first loop will take 4 seconds, while the second takes 3. This looks like 1.5 times faster. If we leave out the execution though, we're looking at 2 seconds compared to 1, and it's 2 times faster. But let's say, then, that we extend the example a bit. Let's say you benchmark using the following query: "select * from abc, def, ghi where abc.id = def.id and ghi.phone = def.phone and ghi.acode like '5%' order by abc.lname;" This query might take eleven seconds. So the benchmark looks like the persistent connection is 12 seconds and the non-persistant is 13. Now it doesn't seem so great. (1.08333) So which is appropriate for you? Whatever best compares to where you'll be using it. Remember that using a query in the benchmark isn't testing your connection speed with persistent connections, it's testing your site's overall speed with persistent connections.