mysql_connect VS mysql_pconnect [closed]

Persistent connections should be unnecessary for MySQL. In other databases (such as Oracle), making a connection is expensive and time-consuming, so if you can re-use a connection it’s a big win. But those brands of database offer connection pooling, which solves the problem in a better way.

Making a connection to a MySQL database is quick compared to those other brands, so using persistent connections gives proportionally less benefit for MySQL than it would for another brand of database.

Persistent connections have a downside too. The database server allocates resources to each connection, whether the connections are needed or not. So you see a lot of wasted resources for no purpose if the connections are idle. I don’t know if you’ll reach 10,000 idle connections, but even a couple of hundred is costly.

Connections have state, and it would be inappropriate for a PHP request to “inherit” information from a session previously used by another PHP request. For example, temporary tables and user variables are normally cleaned up as a connection closes, but not if you use persistent connections. Likewise session-based settings like character set and collation. Also, LAST_INSERT_ID() would report the id last generated during the session — even if that was during a prior PHP request.

For MySQL at least, the downside of persistent connections probably outweighs their benefits. And there are other, better techniques to achieve high scalability.


Update March 2014:

MySQL connection speed was always low compared to other brands of RDBMS, but it’s getting even better.

See http://mysqlserverteam.com/improving-connectdisconnect-performance/

In MySQL 5.6 we started working on optimizing the code handling connects and disconnects. And this work has accelerated in MySQL 5.7. In this blog post I will first show the results we have achieved and then describe what we have done to get them.

Read the blog for more details and speed comparisons.

Leave a Comment