Permanent data connection mysql_pconnect

Mysql_pconnect () and mysql_connect () are very similar, but there are two main differences. First, when connecting, this function will first try to find a (persistent) connection that has been opened with the same user name and password on the same host. if it is found, returns the connection id and... syntaxHighlighter. all ()

Mysql_pconnect () and mysql_connect () are very similar, but there are two main differences.

First, when connecting, this function will first try to find a (persistent) connection that has been opened with the same user name and password on the same host. if it is found, the connection id is returned without a new connection.

Second, after the script is executed, the connection to the SQL Server will not be closed. this connection will be enabled for future use (mysql_close () will not close the connection established by mysql_pconnect ).

A permanent database connection is a connection that is not closed when the script ends running. When receiving a permanent connection request. PHP will check whether there is already a permanent connection (previously enabled. If yes, the connection is directly used. If no, a new connection is established. The "same" connection refers to the connection to the same host with the same user name and password.

Readers who do not fully understand the work and distributed load of web servers may mistakenly understand the role of permanent connections. In particular, permanent connections do not provide the ability to establish "user sessions" on the same connection, nor can they effectively establish transactions. In fact, in a strict sense, permanent connections do not provide any special functions that cannot be provided by non-permanent connections.

Why?

This is related to how the web server works. The web server can generate web pages using PHP in three ways.

The first method is to use PHP as a "shell ". Running in this way, PHP will generate and end a PHP interpreter thread for each PHP page request sent to the web server. Since this thread ends with the end of each request, any resources used in this thread (such as connections to the SQL database server) will be closed with the end of the thread. In this case, using a permanent connection won't be changed-because they are not permanent at all.

The second and most common method is to use PHP as a module of a multi-process web server. this method is only applicable to Apache at present. For a multi-process server, a typical feature is that a parent process is running in coordination with a group of sub-processes. The child process is actually generated on the web page. When a client sends a request to the parent process, the request is sent to a child process that is not occupied by other client requests. This means that when the same client sends a second request to the server, it may be processed by a different sub-process. After a permanent connection is enabled, all subsequent pages requesting SQL service can re-use the established SQL Server connection.

The last method is to use PHP as a plug-in for multi-threaded web servers. Currently, PHP 4 supports ISAPI, WSAPI, and NSAPI (in Windows), which allows PHP to be used as Netscape FastTrack (iPlanet), Microsoft's Internet Information Server (IIS) and O 'Reilly's WebSite Pro. The behavior of permanent connection is essentially the same as the multi-process model described above. Note that PHP 3 does not support SAPI.

If the persistent connection does not have any additional functions, what are the advantages of using it?

The answer is very simple-efficiency. When the client has frequent connection requests to the SQL Server, permanent connection is more efficient. The criteria for frequent connection requests depend on many factors. For example, the database type, whether the database service and web service are on the same server, and how the SQL server loads the load. But at least we know that when there are frequent connection requests, permanent connections will significantly improve the efficiency. It allows each sub-process to perform only one connection operation in its lifecycle, rather than submitting a connection request to the SQL server every time it processes a page. This means that each sub-process will establish a separate permanent connection to the server. For example, if 20 different sub-processes run a script to establish a permanent connection to the SQL Server, 20 different permanent connections are established to the SQL Server, each process occupies one.

Note: If the number of permanent sub-processes exceeds the set number of database connections limit, the system will have some defects. If the number of concurrent connections in the database is limited to 16, and 17 threads attempt to connect in the case of busy sessions, one thread cannot connect. If an error occurs in the script that makes the connection unable to be closed (for example, Infinite Loop), 16 connections of the database will be quickly affected. Please refer to the database documentation for instructions on how to handle abandoned and idle connections. Www.2cto.com

Warning
Pay attention to some special issues when using permanent connections. For example, when a data table lock is used in a permanent connection, if the script cannot release the data table lock for any reason, the script using the same connection will be permanently blocked, to restart the httpd service or database service. In addition, when you use transaction processing, if the script ends before the transaction blocking occurs, the blocking will also affect the next script using the same connection. In any situation, you can use the register_shutdown_function () function to register a simple cleanup function to open the data table lock or roll back the transaction. Or a better way is to avoid using permanent connections in scripts that use data table locks or transaction processing. this can fundamentally solve this problem (and, of course, use permanent connections elsewhere ).

The following is an important summary. Permanent connections are designed to establish a one-to-one distribution for normal connections. This means that the script will not change when the permanent connection is replaced with a non-permanent connection. Using a permanent connection may (very) change the efficiency of the script without changing its behavior!

 

Author: wolinxuebin