The difference between mysql_pconnect and mysql_connect is that the P link is a persistent link and does not close the link, even if mysql_close () is used. After the connection is established, the sleep state is maintained, you can use show processlist to check the sleep connections. The advantage of the P link is that the connection is directly returned when new requests exist, the usage of keep-alive is similar to that of the http1.1 protocol. Is it enabled or disabled? Generally, some experts tell you that when there are not many users, you can enable keep-live to maintain connections when dealing with HTTP. The user does not need to open and establish the connection for the first time and then continues browsing, improving the user experience. When the number of users is large, a large number of connections will put a lot of pressure on the server, so we need to find a balance point to determine whether to enable or not. Let's look back at mysql_p's understanding: no satisfactory answer is found on the Internet, however, we can see a perfect explanation in the manual. It seems that we should look at the manual in the future:
Definition:
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.
Let's take a look at the summary in the manual:
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!
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.
Warning there are still some special problems 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 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.
