🕷️ Crawler Inspector

URL Lookup

Direct Parameter Lookup

Raw Queries and Responses

1. Shard Calculation

Query:

Response:

Calculated Shard: 91 (from laksa169)

2. Crawled Status Check

Query:

curl -X POST \
  'http://laksa091.int.ahrefs:8124/' \
  -H 'Content-Type: text/plain' \
  -H 'X-ClickHouse-Database: crawler3' \
  -H 'Authorization: Basic YXBpOg==' \
  -d 'SELECT getAhrefsURLFromUnparsed(src_unparsed) AS found_url, ifNull(toUnixTimestamp(download_stamp), 0) AS crawl_time, ifNull(toUnixTimestamp(props_url_first_seen), 0) AS first_indexed_time, download_http_code AS http_code, src_unparsed AS src_unparsed, src_root_hash AS src_root_hash, history_drop_reason AS history_drop_reason, meta_title AS meta_title, meta_descriptions AS meta_descriptions, attrs_boilerpipe_text AS attrs_boilerpipe_text, attrs_markdown AS attrs_markdown, attrs_readable_markdown AS attrs_readable_markdown, meta_canonical AS meta_canonical FROM crawler3.page_info_local FINAL PREWHERE (src_root_hash, src_unparsed) IN ((getAhrefsRootHashFromUnparsed(getAhrefsUnparsedNoserviceFromURL(\'https://www.php.net/manual/en/features.persistent-connections.php\')), getAhrefsUnparsedNoserviceFromURL(\'https://www.php.net/manual/en/features.persistent-connections.php\'))) FORMAT JSONEachRow'

Response:

{"found_url":"https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php","crawl_time":1776361960,"first_indexed_time":1553530483,"http_code":200,"src_unparsed":"net,php!www,\/manual\/en\/features.persistent-connections.php s443","src_root_hash":"2869005436169329891","history_drop_reason":null,"meta_title":"PHP: Persistent Database Connections - Manual","meta_descriptions":["Persistent Database Connections"],"attrs_boilerpipe_text":"What are Persistent Connections?\nPersistent connections are links that do not close when the\n   execution of your script ends. When a persistent connection is\n   requested, PHP checks if there's already an identical persistent\n   connection (that remained open from earlier) - and if it exists, it\n   uses it. If it does not exist, it creates the link. An 'identical'\n   connection is a connection that was opened to the same host, with\n   the same username and the same password (where applicable).\nThere's no method of requesting a specific connection, or guaranteeing\n   whether you get an existing connection or a brand new one (if all existing\n   connections are in use, or the request is being served by a different worker,\n   which has a separate pool of connections).\nThis means that you cannot use PHP's persistent connections to, for example:\nassign a specific database session to a specific web user\ncreate a large transaction across multiple requests\ninitiate a query on one request and collect the results on another\nPersistent connections do not give you\nany\nfunctionality that wasn't possible with non-persistent connections.\nWeb Requests\nThere are two ways in which your web server can utilize PHP to generate\n   web pages:\nThe first method is to use PHP as a CGI \"wrapper\". When run this\n   way, an instance of the PHP interpreter is created and destroyed\n   for every page request (for a PHP page) to your web server.\n   Because it is destroyed after every request, any resources that it\n   acquires (such as a link to an SQL database server) are closed when\n   it is destroyed. In this case, you do not gain anything from trying\n   to use persistent connections - they simply don't persist.\nThe second, and most popular, method is to run PHP-FPM, or PHP as a module\n   in a multiprocess web server, which currently only includes Apache.\n   These setups typically have one process (the parent) which\n   coordinates a set of processes (its children) who actually do the\n   work of serving up web pages. When a request comes in from a\n   client, it is handed off to one of the children that is not already\n   serving another client. This means that when the same client makes\n   a second request to the server, it may be served by a different\n   child process than the first time. When opening a persistent connection,\n   every following page requesting SQL services can reuse the same\n   established connection to the SQL server.\nNote\n:\nYou can check which method your web requests use by checking the value of\n   \"Server API\" in the output of\nphpinfo()\nor the value of\nPHP_SAPI\n, run from a web request.\nIf the Server API is \"Apache 2 Handler\" or \"FPM\/FastCGI\", then persistent\n    connections will be used across requests served by the same worker. For any\n    other value, persistent connections will not persist after each request.\nCommand-line Processes\nAs command-line PHP uses a new process for each script, persistent\n   connections are not shared between command-line scripts, so there is no\n   value in using them in transient scripts such as crons or commands.\n   However, they may be useful if, for example, you're writing a long-running\n   application server that serves many requests or tasks and each may need\n   their own database connection.\nWhy Use Them?\nPersistent connections are good if the overhead to create a link to your\n   SQL server is high. Whether or not this overhead is really high depends\n   on many factors. Like, what kind of database it is, whether or not\n   it sits on the same computer on which your web server sits, how\n   loaded the machine the SQL server sits on is and so forth. The\n   bottom line is that if that connection overhead is high, persistent\n   connections help you considerably. They cause the child process to\n   simply connect only once for its entire lifespan, instead of every\n   time it processes a page that requires connecting to the SQL\n   server. This means that for every child that opened a persistent\n   connection will have its own open persistent connection to the\n   server. For example, if you had 20 different child processes that\n   ran a script that made a persistent connection to your SQL server,\n   you'd have 20 different connections to the SQL server, one from\n   each child.\nPotential Drawbacks: Connection Limits\nNote, however, that this can have some drawbacks if you are using a\n   database with connection limits that are exceeded by persistent\n   child connections. If your database has a limit of 16 simultaneous\n   connections, and in the course of a busy server session, 17 child\n   threads attempt to connect, one will not be able to. If there are\n   bugs in your scripts which do not allow the connections to shut\n   down (such as infinite loops), the database with only 16 connections\n   may be rapidly swamped.\nPersistent connections will usually increase the number of connections open\n   at any given time because idle workers will still hold the connections for\n   the previous requests they served. If a large number of workers is spun up to\n   handle an influx of requests, the connections they opened will remain until\n   the worker is killed or the database server closes the connection.\nEnsure that the maximum number of connections allowed by the database server\n   is greater than the maximum number of web request workers (plus any other\n   usage such as crons or administrative connections).\nCheck your database documentation for information on handling abandoned or\n   idle connections (timeouts). Long timeouts may significantly increase the\n   number of persistent connections open at any one time.\nPotential Drawbacks: Maintaining Connection State\nSome database extensions perform automatic cleanup when the connection is\n   reused; others leave this task at the discretion of the application developer.\n   Depending on the chosen database extension and the application design, manual\n   cleanup may be needed before the script exits. Changes that may leave\n   connections in an unexpected state include:\nSelected \/ default database\nTable locks\nUncommitted transactions\nTemporary tables\nConnection specific settings or features such as profiling\nTable locks and transactions that are not cleaned up or closed may cause\n   other queries to be blocked indefinitely and\/or cause subsequent reuse of\n   the connection to cause unexpected changes.\nHaving the wrong database selected will cause subsequent reuse of the\n   connection to be unable to execute queries as expected (or execute them on\n   the wrong database if schemas are similar enough).\nIf temporary tables are not cleaned up, subsequent requests will not be able\n   to recreate the same table.\nYou can implement cleanup using class destructors or\nregister_shutdown_function()\n. You may also want to\n   consider dedicated connection pooling proxies that include this as part of\n   their functionality.\nFinal Words\nGiven their behavior and potential drawbacks described above, you should not\n   use persistent connections without careful consideration. They should not be\n   used without implementing additional changes to your application and careful\n   configuration of your database server and web server and\/or PHP-FPM.\nConsider alternative solutions such as investigating and fixing the causes of\n   connection creation overheads (for example, disabling reverse DNS lookups on\n   the database server), or dedicated connection pooling proxies.\nFor high volume web APIs, consider using alternative runtimes or long-running\n   application servers.\nSee Also\nibase_pconnect()\noci_pconnect()\nodbc_pconnect()\npfsockopen()\npg_connect()\nMySQLi and Persistent Connections\nPDO Connection Management\n22\nTom\n¶\n16 years ago\nThere's a third case for PHP: run on a fastCGI interface. In this case, PHP processes are NOT destroyed after each request, and so persistent connections do persist. Set PHP_FCGI_CHILDREN << mysql's max_connections and you'll be fine.\n14\nambrish at php dot net\n¶\n15 years ago\nIn IBM_DB2 extension v1.9.0 or later performs a transaction rollback on persistent connections at the end of a request, thus ending the transaction. This prevents the transaction block from carrying over to the next request which uses that connection if script execution ends before the transaction block does.\n14\nphp at alfadog dot net\n¶\n12 years ago\nOne additional not regarding odbc_pconnect  and possibly other variations of pconnect:\n \nIf the connection encounters an error (bad SQL, incorrect request, etc), that error will return with  be present in odbc_errormsg for every subsequent action on that connection, even if subsequent actions don't cause another error.\n\nFor example:\n\nA script connects with odbc_pconnect.\nThe connection is created on it's first use.\nThe script calls a query \"Select * FROM Table1\".\nTable1 doesn't exist and odbc_errormsg contains that error.\n\nLater(days, perhaps), a different script is called using the same parameters to odbc_pconnect.\nThe connection already exists, to it is reused.\nThe script calls a query \"Select * FROM Table0\".\nThe query runs fine, but odbc_errormsg still returns the error about Table1 not existing.\n\nI'm not seeing a way to clear that error using odbc_ functions, so keep your eyes open for this gotcha or use odbc_connect instead.\n14\nchristopher dot jones at oracle dot com\n¶\n18 years ago\nFor the oci8 extension it is not true that \" [...] when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does.\".  The oci8 extension does a rollback at the end scripts using persistent connections, thus ending the transaction.  The rollback also releases locks. However any ALTER SESSION command (e.g. changing the date format) on a persistent connection will be retained over to the next script.\n11\nynzhang from lakeheadu canada\n¶\n17 years ago\nIt seems that using pg_pconnect() will not persist the temporary views\/tables. So if you are trying to create temporary views\/tables with the query results and then access them with the next script of the same session, you are out of luck. Those temporary view\/tables are gone after each PHP script ended. One way to get around this problem is to create real view\/table with session ID as part of the name and record the name&creation time in a common table. Have a garbage collection script to drop the view\/table who's session is expired.\n10\njean_christian at myrealbox dot com\n¶\n23 years ago\nIf anyone ever wonders why the number of idle db process (open connections) seems to grow even though you are using persistent connections, here's why:\n\n\"You are probably using a multi-process web server such as Apache. Since\ndatabase connections cannot be shared among different processes a new\none is created if the request happen to come to a different web server\nchild process.\"\n8\nandy at paradigm-reborn dot com\n¶\n19 years ago\nTo those using MySQL and finding a lot of leftover sleeping processes, take a look at MySQL's wait_timeout directive. By default it is set to 8 hours, but almost any decent production server will have been lowered to the 60 second range. Even on my testing server, I was having problems with too many connections from leftover persistent connections.","attrs_markdown":"[update page now](https:\/\/www.php.net\/x-myracloud-5958a2bbbed300a9b9ac631223924e0b\/1776361960.371)\n\n[![](https:\/\/www.php.net\/images\/logos\/php-logo-white.svg)](https:\/\/www.php.net\/)\n\n- [Downloads](https:\/\/www.php.net\/downloads.php)\n- [Documentation](https:\/\/www.php.net\/docs.php)\n- [Get Involved](https:\/\/www.php.net\/get-involved.php)\n- [Help](https:\/\/www.php.net\/support.php)\n- [![PHP 8.5](https:\/\/www.php.net\/images\/php8\/logo_php8_5.svg)](https:\/\/www.php.net\/releases\/8.5\/index.php)\n\nSearch docs\n\n[Getting Started](https:\/\/www.php.net\/manual\/en\/getting-started.php)\n\n[Introduction](https:\/\/www.php.net\/manual\/en\/introduction.php)\n\n[A simple tutorial](https:\/\/www.php.net\/manual\/en\/tutorial.php)\n\n[Language Reference](https:\/\/www.php.net\/manual\/en\/langref.php)\n\n[Basic syntax](https:\/\/www.php.net\/manual\/en\/language.basic-syntax.php)\n\n[Types](https:\/\/www.php.net\/manual\/en\/language.types.php)\n\n[Variables](https:\/\/www.php.net\/manual\/en\/language.variables.php)\n\n[Constants](https:\/\/www.php.net\/manual\/en\/language.constants.php)\n\n[Expressions](https:\/\/www.php.net\/manual\/en\/language.expressions.php)\n\n[Operators](https:\/\/www.php.net\/manual\/en\/language.operators.php)\n\n[Control Structures](https:\/\/www.php.net\/manual\/en\/language.control-structures.php)\n\n[Functions](https:\/\/www.php.net\/manual\/en\/language.functions.php)\n\n[Classes and Objects](https:\/\/www.php.net\/manual\/en\/language.oop5.php)\n\n[Namespaces](https:\/\/www.php.net\/manual\/en\/language.namespaces.php)\n\n[Enumerations](https:\/\/www.php.net\/manual\/en\/language.enumerations.php)\n\n[Errors](https:\/\/www.php.net\/manual\/en\/language.errors.php)\n\n[Exceptions](https:\/\/www.php.net\/manual\/en\/language.exceptions.php)\n\n[Fibers](https:\/\/www.php.net\/manual\/en\/language.fibers.php)\n\n[Generators](https:\/\/www.php.net\/manual\/en\/language.generators.php)\n\n[Attributes](https:\/\/www.php.net\/manual\/en\/language.attributes.php)\n\n[References Explained](https:\/\/www.php.net\/manual\/en\/language.references.php)\n\n[Predefined Variables](https:\/\/www.php.net\/manual\/en\/reserved.variables.php)\n\n[Predefined Exceptions](https:\/\/www.php.net\/manual\/en\/reserved.exceptions.php)\n\n[Predefined Interfaces and Classes](https:\/\/www.php.net\/manual\/en\/reserved.interfaces.php)\n\n[Predefined Attributes](https:\/\/www.php.net\/manual\/en\/reserved.attributes.php)\n\n[Context options and parameters](https:\/\/www.php.net\/manual\/en\/context.php)\n\n[Supported Protocols and Wrappers](https:\/\/www.php.net\/manual\/en\/wrappers.php)\n\n[Security](https:\/\/www.php.net\/manual\/en\/security.php)\n\n[Introduction](https:\/\/www.php.net\/manual\/en\/security.intro.php)\n\n[General considerations](https:\/\/www.php.net\/manual\/en\/security.general.php)\n\n[Installed as CGI binary](https:\/\/www.php.net\/manual\/en\/security.cgi-bin.php)\n\n[Installed as an Apache module](https:\/\/www.php.net\/manual\/en\/security.apache.php)\n\n[Session Security](https:\/\/www.php.net\/manual\/en\/security.sessions.php)\n\n[Filesystem Security](https:\/\/www.php.net\/manual\/en\/security.filesystem.php)\n\n[Database Security](https:\/\/www.php.net\/manual\/en\/security.database.php)\n\n[Error Reporting](https:\/\/www.php.net\/manual\/en\/security.errors.php)\n\n[User Submitted Data](https:\/\/www.php.net\/manual\/en\/security.variables.php)\n\n[Hiding PHP](https:\/\/www.php.net\/manual\/en\/security.hiding.php)\n\n[Keeping Current](https:\/\/www.php.net\/manual\/en\/security.current.php)\n\n[Features](https:\/\/www.php.net\/manual\/en\/features.php)\n\n[HTTP authentication with PHP](https:\/\/www.php.net\/manual\/en\/features.http-auth.php)\n\n[Cookies](https:\/\/www.php.net\/manual\/en\/features.cookies.php)\n\n[Sessions](https:\/\/www.php.net\/manual\/en\/features.sessions.php)\n\n[Handling file uploads](https:\/\/www.php.net\/manual\/en\/features.file-upload.php)\n\n[Using remote files](https:\/\/www.php.net\/manual\/en\/features.remote-files.php)\n\n[Connection handling](https:\/\/www.php.net\/manual\/en\/features.connection-handling.php)\n\n[Persistent Database Connections](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php)\n\n[Command line usage](https:\/\/www.php.net\/manual\/en\/features.commandline.php)\n\n[Garbage Collection](https:\/\/www.php.net\/manual\/en\/features.gc.php)\n\n[DTrace Dynamic Tracing](https:\/\/www.php.net\/manual\/en\/features.dtrace.php)\n\n[Function Reference](https:\/\/www.php.net\/manual\/en\/funcref.php)\n\n[Affecting PHP's Behaviour](https:\/\/www.php.net\/manual\/en\/refs.basic.php.php)\n\n[Audio Formats Manipulation](https:\/\/www.php.net\/manual\/en\/refs.utilspec.audio.php)\n\n[Authentication Services](https:\/\/www.php.net\/manual\/en\/refs.remote.auth.php)\n\n[Command Line Specific Extensions](https:\/\/www.php.net\/manual\/en\/refs.utilspec.cmdline.php)\n\n[Compression and Archive Extensions](https:\/\/www.php.net\/manual\/en\/refs.compression.php)\n\n[Cryptography Extensions](https:\/\/www.php.net\/manual\/en\/refs.crypto.php)\n\n[Database Extensions](https:\/\/www.php.net\/manual\/en\/refs.database.php)\n\n[Date and Time Related Extensions](https:\/\/www.php.net\/manual\/en\/refs.calendar.php)\n\n[File System Related Extensions](https:\/\/www.php.net\/manual\/en\/refs.fileprocess.file.php)\n\n[Human Language and Character Encoding Support](https:\/\/www.php.net\/manual\/en\/refs.international.php)\n\n[Image Processing and Generation](https:\/\/www.php.net\/manual\/en\/refs.utilspec.image.php)\n\n[Mail Related Extensions](https:\/\/www.php.net\/manual\/en\/refs.remote.mail.php)\n\n[Mathematical Extensions](https:\/\/www.php.net\/manual\/en\/refs.math.php)\n\n[Non-Text MIME Output](https:\/\/www.php.net\/manual\/en\/refs.utilspec.nontext.php)\n\n[Process Control Extensions](https:\/\/www.php.net\/manual\/en\/refs.fileprocess.process.php)\n\n[Other Basic Extensions](https:\/\/www.php.net\/manual\/en\/refs.basic.other.php)\n\n[Other Services](https:\/\/www.php.net\/manual\/en\/refs.remote.other.php)\n\n[Search Engine Extensions](https:\/\/www.php.net\/manual\/en\/refs.search.php)\n\n[Server Specific Extensions](https:\/\/www.php.net\/manual\/en\/refs.utilspec.server.php)\n\n[Session Extensions](https:\/\/www.php.net\/manual\/en\/refs.basic.session.php)\n\n[Text Processing](https:\/\/www.php.net\/manual\/en\/refs.basic.text.php)\n\n[Variable and Type Related Extensions](https:\/\/www.php.net\/manual\/en\/refs.basic.vartype.php)\n\n[Web Services](https:\/\/www.php.net\/manual\/en\/refs.webservice.php)\n\n[Windows Only Extensions](https:\/\/www.php.net\/manual\/en\/refs.utilspec.windows.php)\n\n[XML Manipulation](https:\/\/www.php.net\/manual\/en\/refs.xml.php)\n\n[GUI Extensions](https:\/\/www.php.net\/manual\/en\/refs.ui.php)\n\nKeyboard Shortcuts\n\n?\n\nThis help\n\nj\n\nNext menu item\n\nk\n\nPrevious menu item\n\ng p\n\nPrevious man page\n\ng n\n\nNext man page\n\nG\n\nScroll to bottom\n\ng g\n\nScroll to top\n\ng h\n\nGoto homepage\n\ng s\n\nGoto search  \n(current page)\n\n\/\n\nFocus search box\n\n[Command line usage »](https:\/\/www.php.net\/manual\/en\/features.commandline.php)\n\n[« Connection handling](https:\/\/www.php.net\/manual\/en\/features.connection-handling.php)\n\n- [Preface](https:\/\/www.php.net\/manual\/en\/index.php)\n- [Features](https:\/\/www.php.net\/manual\/en\/features.php)\n\n# Persistent Database Connections\n### What are Persistent Connections?\nPersistent connections are links that do not close when the execution of your script ends. When a persistent connection is requested, PHP checks if there's already an identical persistent connection (that remained open from earlier) - and if it exists, it uses it. If it does not exist, it creates the link. An 'identical' connection is a connection that was opened to the same host, with the same username and the same password (where applicable).\n\nThere's no method of requesting a specific connection, or guaranteeing whether you get an existing connection or a brand new one (if all existing connections are in use, or the request is being served by a different worker, which has a separate pool of connections).\n\nThis means that you cannot use PHP's persistent connections to, for example:\n\n- assign a specific database session to a specific web user\n- create a large transaction across multiple requests\n- initiate a query on one request and collect the results on another\n\nPersistent connections do not give you *any* functionality that wasn't possible with non-persistent connections.\n\n### Web Requests\nThere are two ways in which your web server can utilize PHP to generate web pages:\n\nThe first method is to use PHP as a CGI \"wrapper\". When run this way, an instance of the PHP interpreter is created and destroyed for every page request (for a PHP page) to your web server. Because it is destroyed after every request, any resources that it acquires (such as a link to an SQL database server) are closed when it is destroyed. In this case, you do not gain anything from trying to use persistent connections - they simply don't persist.\n\nThe second, and most popular, method is to run PHP-FPM, or PHP as a module in a multiprocess web server, which currently only includes Apache. These setups typically have one process (the parent) which coordinates a set of processes (its children) who actually do the work of serving up web pages. When a request comes in from a client, it is handed off to one of the children that is not already serving another client. This means that when the same client makes a second request to the server, it may be served by a different child process than the first time. When opening a persistent connection, every following page requesting SQL services can reuse the same established connection to the SQL server.\n\n> **Note**:\n> \n> You can check which method your web requests use by checking the value of \"Server API\" in the output of [phpinfo()](https:\/\/www.php.net\/manual\/en\/function.phpinfo.php) or the value of **`PHP_SAPI`**, run from a web request.\n> \n> If the Server API is \"Apache 2 Handler\" or \"FPM\/FastCGI\", then persistent connections will be used across requests served by the same worker. For any other value, persistent connections will not persist after each request.\n\n### Command-line Processes\nAs command-line PHP uses a new process for each script, persistent connections are not shared between command-line scripts, so there is no value in using them in transient scripts such as crons or commands. However, they may be useful if, for example, you're writing a long-running application server that serves many requests or tasks and each may need their own database connection.\n\n### Why Use Them?\nPersistent connections are good if the overhead to create a link to your SQL server is high. Whether or not this overhead is really high depends on many factors. Like, what kind of database it is, whether or not it sits on the same computer on which your web server sits, how loaded the machine the SQL server sits on is and so forth. The bottom line is that if that connection overhead is high, persistent connections help you considerably. They cause the child process to simply connect only once for its entire lifespan, instead of every time it processes a page that requires connecting to the SQL server. This means that for every child that opened a persistent connection will have its own open persistent connection to the server. For example, if you had 20 different child processes that ran a script that made a persistent connection to your SQL server, you'd have 20 different connections to the SQL server, one from each child.\n\n### Potential Drawbacks: Connection Limits\nNote, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous connections, and in the course of a busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), the database with only 16 connections may be rapidly swamped.\n\nPersistent connections will usually increase the number of connections open at any given time because idle workers will still hold the connections for the previous requests they served. If a large number of workers is spun up to handle an influx of requests, the connections they opened will remain until the worker is killed or the database server closes the connection.\n\nEnsure that the maximum number of connections allowed by the database server is greater than the maximum number of web request workers (plus any other usage such as crons or administrative connections).\n\nCheck your database documentation for information on handling abandoned or idle connections (timeouts). Long timeouts may significantly increase the number of persistent connections open at any one time.\n\n### Potential Drawbacks: Maintaining Connection State\nSome database extensions perform automatic cleanup when the connection is reused; others leave this task at the discretion of the application developer. Depending on the chosen database extension and the application design, manual cleanup may be needed before the script exits. Changes that may leave connections in an unexpected state include:\n\n- Selected \/ default database\n- Table locks\n- Uncommitted transactions\n- Temporary tables\n- Connection specific settings or features such as profiling\n\nTable locks and transactions that are not cleaned up or closed may cause other queries to be blocked indefinitely and\/or cause subsequent reuse of the connection to cause unexpected changes.\n\nHaving the wrong database selected will cause subsequent reuse of the connection to be unable to execute queries as expected (or execute them on the wrong database if schemas are similar enough).\n\nIf temporary tables are not cleaned up, subsequent requests will not be able to recreate the same table.\n\nYou can implement cleanup using class destructors or [register\\_shutdown\\_function()](https:\/\/www.php.net\/manual\/en\/function.register-shutdown-function.php). You may also want to consider dedicated connection pooling proxies that include this as part of their functionality.\n\n### Final Words\nGiven their behavior and potential drawbacks described above, you should not use persistent connections without careful consideration. They should not be used without implementing additional changes to your application and careful configuration of your database server and web server and\/or PHP-FPM.\n\nConsider alternative solutions such as investigating and fixing the causes of connection creation overheads (for example, disabling reverse DNS lookups on the database server), or dedicated connection pooling proxies.\n\nFor high volume web APIs, consider using alternative runtimes or long-running application servers.\n\n### See Also\n- [ibase\\_pconnect()](https:\/\/www.php.net\/manual\/en\/function.ibase-pconnect.php)\n- [oci\\_pconnect()](https:\/\/www.php.net\/manual\/en\/function.oci-pconnect.php)\n- [odbc\\_pconnect()](https:\/\/www.php.net\/manual\/en\/function.odbc-pconnect.php)\n- [pfsockopen()](https:\/\/www.php.net\/manual\/en\/function.pfsockopen.php)\n- [pg\\_connect()](https:\/\/www.php.net\/manual\/en\/function.pg-connect.php)\n- [MySQLi and Persistent Connections](https:\/\/www.php.net\/manual\/en\/mysqli.persistconns.php)\n- [PDO Connection Management](https:\/\/www.php.net\/manual\/en\/pdo.connections.php)\n\n### Found A Problem?\n[Learn How To Improve This Page](https:\/\/github.com\/php\/doc-base\/blob\/master\/README.md \"This will take you to our contribution guidelines on GitHub\") • [Submit a Pull Request](https:\/\/github.com\/php\/doc-en\/blob\/master\/features\/persistent-connections.xml) • [Report a Bug](https:\/\/github.com\/php\/doc-en\/issues\/new?body=From%20manual%20page:%20https:%2F%2Fphp.net%2Ffeatures.persistent-connections%0A%0A---)\n\n[＋add a note](https:\/\/www.php.net\/manual\/add-note.php?sect=features.persistent-connections&repo=en&redirect=https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php)\n\n### User Contributed Notes 7 notes\n\n[up](https:\/\/www.php.net\/manual\/vote-note.php?id=95340&page=features.persistent-connections&vote=up \"Vote up!\")\n\n[down](https:\/\/www.php.net\/manual\/vote-note.php?id=95340&page=features.persistent-connections&vote=down \"Vote down!\")\n\n22\n\n[***Tom***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#95340) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#95340)\n\n**16 years ago**\n```\nThere's a third case for PHP: run on a fastCGI interface. In this case, PHP processes are NOT destroyed after each request, and so persistent connections do persist. Set PHP_FCGI_CHILDREN << mysql's max_connections and you'll be fine.\n```\n\n[up](https:\/\/www.php.net\/manual\/vote-note.php?id=100009&page=features.persistent-connections&vote=up \"Vote up!\")\n\n[down](https:\/\/www.php.net\/manual\/vote-note.php?id=100009&page=features.persistent-connections&vote=down \"Vote down!\")\n\n14\n\n[***ambrish at php dot net***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#100009) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#100009)\n\n**15 years ago**\n```\nIn IBM_DB2 extension v1.9.0 or later performs a transaction rollback on persistent connections at the end of a request, thus ending the transaction. This prevents the transaction block from carrying over to the next request which uses that connection if script execution ends before the transaction block does.\n```\n\n[up](https:\/\/www.php.net\/manual\/vote-note.php?id=114190&page=features.persistent-connections&vote=up \"Vote up!\")\n\n[down](https:\/\/www.php.net\/manual\/vote-note.php?id=114190&page=features.persistent-connections&vote=down \"Vote down!\")\n\n14\n\n[***php at alfadog dot net***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#114190) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#114190)\n\n**12 years ago**\n```\nOne additional not regarding odbc_pconnect  and possibly other variations of pconnect:\n \nIf the connection encounters an error (bad SQL, incorrect request, etc), that error will return with  be present in odbc_errormsg for every subsequent action on that connection, even if subsequent actions don't cause another error.\n\nFor example:\n\nA script connects with odbc_pconnect.\nThe connection is created on it's first use.\nThe script calls a query \"Select * FROM Table1\".\nTable1 doesn't exist and odbc_errormsg contains that error.\n\nLater(days, perhaps), a different script is called using the same parameters to odbc_pconnect.\nThe connection already exists, to it is reused.\nThe script calls a query \"Select * FROM Table0\".\nThe query runs fine, but odbc_errormsg still returns the error about Table1 not existing.\n\nI'm not seeing a way to clear that error using odbc_ functions, so keep your eyes open for this gotcha or use odbc_connect instead.\n```\n\n[up](https:\/\/www.php.net\/manual\/vote-note.php?id=76013&page=features.persistent-connections&vote=up \"Vote up!\")\n\n[down](https:\/\/www.php.net\/manual\/vote-note.php?id=76013&page=features.persistent-connections&vote=down \"Vote down!\")\n\n14\n\n[***christopher dot jones at oracle dot com***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#76013) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#76013)\n\n**18 years ago**\n```\nFor the oci8 extension it is not true that \" [...] when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does.\".  The oci8 extension does a rollback at the end scripts using persistent connections, thus ending the transaction.  The rollback also releases locks. However any ALTER SESSION command (e.g. changing the date format) on a persistent connection will be retained over to the next script.\n```\n\n[up](https:\/\/www.php.net\/manual\/vote-note.php?id=89465&page=features.persistent-connections&vote=up \"Vote up!\")\n\n[down](https:\/\/www.php.net\/manual\/vote-note.php?id=89465&page=features.persistent-connections&vote=down \"Vote down!\")\n\n11\n\n[***ynzhang from lakeheadu canada***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#89465) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#89465)\n\n**17 years ago**\n```\nIt seems that using pg_pconnect() will not persist the temporary views\/tables. So if you are trying to create temporary views\/tables with the query results and then access them with the next script of the same session, you are out of luck. Those temporary view\/tables are gone after each PHP script ended. One way to get around this problem is to create real view\/table with session ID as part of the name and record the name&creation time in a common table. Have a garbage collection script to drop the view\/table who's session is expired.\n```\n\n[up](https:\/\/www.php.net\/manual\/vote-note.php?id=24393&page=features.persistent-connections&vote=up \"Vote up!\")\n\n[down](https:\/\/www.php.net\/manual\/vote-note.php?id=24393&page=features.persistent-connections&vote=down \"Vote down!\")\n\n10\n\n[***jean\\_christian at myrealbox dot com***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#24393) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#24393)\n\n**23 years ago**\n```\nIf anyone ever wonders why the number of idle db process (open connections) seems to grow even though you are using persistent connections, here's why:\n\n\"You are probably using a multi-process web server such as Apache. Since\ndatabase connections cannot be shared among different processes a new\none is created if the request happen to come to a different web server\nchild process.\"\n```\n\n[up](https:\/\/www.php.net\/manual\/vote-note.php?id=73370&page=features.persistent-connections&vote=up \"Vote up!\")\n\n[down](https:\/\/www.php.net\/manual\/vote-note.php?id=73370&page=features.persistent-connections&vote=down \"Vote down!\")\n\n8\n\n[***andy at paradigm-reborn dot com***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#73370) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#73370)\n\n**19 years ago**\n```\nTo those using MySQL and finding a lot of leftover sleeping processes, take a look at MySQL's wait_timeout directive. By default it is set to 8 hours, but almost any decent production server will have been lowered to the 60 second range. Even on my testing server, I was having problems with too many connections from leftover persistent connections.\n```\n\n[＋add a note](https:\/\/www.php.net\/manual\/add-note.php?sect=features.persistent-connections&repo=en&redirect=https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php)\n\n- [Features](https:\/\/www.php.net\/manual\/en\/features.php)\n  - [HTTP authentication with PHP](https:\/\/www.php.net\/manual\/en\/features.http-auth.php \"HTTP authentication with PHP\")\n  - [Cookies](https:\/\/www.php.net\/manual\/en\/features.cookies.php \"Cookies\")\n  - [Sessions](https:\/\/www.php.net\/manual\/en\/features.sessions.php \"Sessions\")\n  - [Handling file uploads](https:\/\/www.php.net\/manual\/en\/features.file-upload.php \"Handling file uploads\")\n  - [Using remote files](https:\/\/www.php.net\/manual\/en\/features.remote-files.php \"Using remote files\")\n  - [Connection handling](https:\/\/www.php.net\/manual\/en\/features.connection-handling.php \"Connection handling\")\n  - [Persistent Database Connections](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php \"Persistent Database Connections\")\n  - [Command line usage](https:\/\/www.php.net\/manual\/en\/features.commandline.php \"Command line usage\")\n  - [Garbage Collection](https:\/\/www.php.net\/manual\/en\/features.gc.php \"Garbage Collection\")\n  - [DTrace Dynamic Tracing](https:\/\/www.php.net\/manual\/en\/features.dtrace.php \"DTrace Dynamic Tracing\")\n\n- [Copyright © 2001-2026 The PHP Documentation Group](https:\/\/www.php.net\/manual\/en\/copyright.php)\n- [My PHP.net](https:\/\/www.php.net\/my.php)\n- [Contact](https:\/\/www.php.net\/contact.php)\n- [Other PHP.net sites](https:\/\/www.php.net\/sites.php)\n- [Privacy policy](https:\/\/www.php.net\/privacy.php)\n\n[![To Top](https:\/\/www.php.net\/images\/to-top@2x.png)]()\n\n`↑` and `↓` to navigate • `Enter` to select • `Esc` to close • `\/` to open\n\nPress `Enter` without selection to search using Google","attrs_readable_markdown":"### What are Persistent Connections?\nPersistent connections are links that do not close when the execution of your script ends. When a persistent connection is requested, PHP checks if there's already an identical persistent connection (that remained open from earlier) - and if it exists, it uses it. If it does not exist, it creates the link. An 'identical' connection is a connection that was opened to the same host, with the same username and the same password (where applicable).\n\nThere's no method of requesting a specific connection, or guaranteeing whether you get an existing connection or a brand new one (if all existing connections are in use, or the request is being served by a different worker, which has a separate pool of connections).\n\nThis means that you cannot use PHP's persistent connections to, for example:\n\n- assign a specific database session to a specific web user\n- create a large transaction across multiple requests\n- initiate a query on one request and collect the results on another\n\nPersistent connections do not give you *any* functionality that wasn't possible with non-persistent connections.\n\n### Web Requests\nThere are two ways in which your web server can utilize PHP to generate web pages:\n\nThe first method is to use PHP as a CGI \"wrapper\". When run this way, an instance of the PHP interpreter is created and destroyed for every page request (for a PHP page) to your web server. Because it is destroyed after every request, any resources that it acquires (such as a link to an SQL database server) are closed when it is destroyed. In this case, you do not gain anything from trying to use persistent connections - they simply don't persist.\n\nThe second, and most popular, method is to run PHP-FPM, or PHP as a module in a multiprocess web server, which currently only includes Apache. These setups typically have one process (the parent) which coordinates a set of processes (its children) who actually do the work of serving up web pages. When a request comes in from a client, it is handed off to one of the children that is not already serving another client. This means that when the same client makes a second request to the server, it may be served by a different child process than the first time. When opening a persistent connection, every following page requesting SQL services can reuse the same established connection to the SQL server.\n\n> **Note**:\n> \n> You can check which method your web requests use by checking the value of \"Server API\" in the output of [phpinfo()](https:\/\/www.php.net\/manual\/en\/function.phpinfo.php) or the value of **`PHP_SAPI`**, run from a web request.\n> \n> If the Server API is \"Apache 2 Handler\" or \"FPM\/FastCGI\", then persistent connections will be used across requests served by the same worker. For any other value, persistent connections will not persist after each request.\n\n### Command-line Processes\nAs command-line PHP uses a new process for each script, persistent connections are not shared between command-line scripts, so there is no value in using them in transient scripts such as crons or commands. However, they may be useful if, for example, you're writing a long-running application server that serves many requests or tasks and each may need their own database connection.\n\n### Why Use Them?\nPersistent connections are good if the overhead to create a link to your SQL server is high. Whether or not this overhead is really high depends on many factors. Like, what kind of database it is, whether or not it sits on the same computer on which your web server sits, how loaded the machine the SQL server sits on is and so forth. The bottom line is that if that connection overhead is high, persistent connections help you considerably. They cause the child process to simply connect only once for its entire lifespan, instead of every time it processes a page that requires connecting to the SQL server. This means that for every child that opened a persistent connection will have its own open persistent connection to the server. For example, if you had 20 different child processes that ran a script that made a persistent connection to your SQL server, you'd have 20 different connections to the SQL server, one from each child.\n\n### Potential Drawbacks: Connection Limits\nNote, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous connections, and in the course of a busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), the database with only 16 connections may be rapidly swamped.\n\nPersistent connections will usually increase the number of connections open at any given time because idle workers will still hold the connections for the previous requests they served. If a large number of workers is spun up to handle an influx of requests, the connections they opened will remain until the worker is killed or the database server closes the connection.\n\nEnsure that the maximum number of connections allowed by the database server is greater than the maximum number of web request workers (plus any other usage such as crons or administrative connections).\n\nCheck your database documentation for information on handling abandoned or idle connections (timeouts). Long timeouts may significantly increase the number of persistent connections open at any one time.\n\n### Potential Drawbacks: Maintaining Connection State\nSome database extensions perform automatic cleanup when the connection is reused; others leave this task at the discretion of the application developer. Depending on the chosen database extension and the application design, manual cleanup may be needed before the script exits. Changes that may leave connections in an unexpected state include:\n\n- Selected \/ default database\n- Table locks\n- Uncommitted transactions\n- Temporary tables\n- Connection specific settings or features such as profiling\n\nTable locks and transactions that are not cleaned up or closed may cause other queries to be blocked indefinitely and\/or cause subsequent reuse of the connection to cause unexpected changes.\n\nHaving the wrong database selected will cause subsequent reuse of the connection to be unable to execute queries as expected (or execute them on the wrong database if schemas are similar enough).\n\nIf temporary tables are not cleaned up, subsequent requests will not be able to recreate the same table.\n\nYou can implement cleanup using class destructors or [register\\_shutdown\\_function()](https:\/\/www.php.net\/manual\/en\/function.register-shutdown-function.php). You may also want to consider dedicated connection pooling proxies that include this as part of their functionality.\n\n### Final Words\nGiven their behavior and potential drawbacks described above, you should not use persistent connections without careful consideration. They should not be used without implementing additional changes to your application and careful configuration of your database server and web server and\/or PHP-FPM.\n\nConsider alternative solutions such as investigating and fixing the causes of connection creation overheads (for example, disabling reverse DNS lookups on the database server), or dedicated connection pooling proxies.\n\nFor high volume web APIs, consider using alternative runtimes or long-running application servers.\n\n### See Also\n- [ibase\\_pconnect()](https:\/\/www.php.net\/manual\/en\/function.ibase-pconnect.php)\n- [oci\\_pconnect()](https:\/\/www.php.net\/manual\/en\/function.oci-pconnect.php)\n- [odbc\\_pconnect()](https:\/\/www.php.net\/manual\/en\/function.odbc-pconnect.php)\n- [pfsockopen()](https:\/\/www.php.net\/manual\/en\/function.pfsockopen.php)\n- [pg\\_connect()](https:\/\/www.php.net\/manual\/en\/function.pg-connect.php)\n- [MySQLi and Persistent Connections](https:\/\/www.php.net\/manual\/en\/mysqli.persistconns.php)\n- [PDO Connection Management](https:\/\/www.php.net\/manual\/en\/pdo.connections.php)\n\n22\n\n[***Tom***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#95340) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#95340)\n\n**16 years ago**\n```\nThere's a third case for PHP: run on a fastCGI interface. In this case, PHP processes are NOT destroyed after each request, and so persistent connections do persist. Set PHP_FCGI_CHILDREN << mysql's max_connections and you'll be fine.\n```\n\n14\n\n[***ambrish at php dot net***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#100009) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#100009)\n\n**15 years ago**\n```\nIn IBM_DB2 extension v1.9.0 or later performs a transaction rollback on persistent connections at the end of a request, thus ending the transaction. This prevents the transaction block from carrying over to the next request which uses that connection if script execution ends before the transaction block does.\n```\n\n14\n\n[***php at alfadog dot net***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#114190) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#114190)\n\n**12 years ago**\n```\nOne additional not regarding odbc_pconnect  and possibly other variations of pconnect:\n \nIf the connection encounters an error (bad SQL, incorrect request, etc), that error will return with  be present in odbc_errormsg for every subsequent action on that connection, even if subsequent actions don't cause another error.\n\nFor example:\n\nA script connects with odbc_pconnect.\nThe connection is created on it's first use.\nThe script calls a query \"Select * FROM Table1\".\nTable1 doesn't exist and odbc_errormsg contains that error.\n\nLater(days, perhaps), a different script is called using the same parameters to odbc_pconnect.\nThe connection already exists, to it is reused.\nThe script calls a query \"Select * FROM Table0\".\nThe query runs fine, but odbc_errormsg still returns the error about Table1 not existing.\n\nI'm not seeing a way to clear that error using odbc_ functions, so keep your eyes open for this gotcha or use odbc_connect instead.\n```\n\n14\n\n[***christopher dot jones at oracle dot com***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#76013) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#76013)\n\n**18 years ago**\n```\nFor the oci8 extension it is not true that \" [...] when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does.\".  The oci8 extension does a rollback at the end scripts using persistent connections, thus ending the transaction.  The rollback also releases locks. However any ALTER SESSION command (e.g. changing the date format) on a persistent connection will be retained over to the next script.\n```\n\n11\n\n[***ynzhang from lakeheadu canada***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#89465) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#89465)\n\n**17 years ago**\n```\nIt seems that using pg_pconnect() will not persist the temporary views\/tables. So if you are trying to create temporary views\/tables with the query results and then access them with the next script of the same session, you are out of luck. Those temporary view\/tables are gone after each PHP script ended. One way to get around this problem is to create real view\/table with session ID as part of the name and record the name&creation time in a common table. Have a garbage collection script to drop the view\/table who's session is expired.\n```\n\n10\n\n[***jean\\_christian at myrealbox dot com***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#24393) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#24393)\n\n**23 years ago**\n```\nIf anyone ever wonders why the number of idle db process (open connections) seems to grow even though you are using persistent connections, here's why:\n\n\"You are probably using a multi-process web server such as Apache. Since\ndatabase connections cannot be shared among different processes a new\none is created if the request happen to come to a different web server\nchild process.\"\n```\n\n8\n\n[***andy at paradigm-reborn dot com***](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#73370) [¶](https:\/\/www.php.net\/manual\/en\/features.persistent-connections.php#73370)\n\n**19 years ago**\n```\nTo those using MySQL and finding a lot of leftover sleeping processes, take a look at MySQL's wait_timeout directive. By default it is set to 8 hours, but almost any decent production server will have been lowered to the 60 second range. Even on my testing server, I was having problems with too many connections from leftover persistent connections.\n```","meta_canonical":null}

3. Robots.txt Check

Query:

Response:

4. Spam/Ban Check

Query:

Response:

5. Seen Status Check

ℹ️ Skipped - page is already crawled

📄

INDEXABLE

✅

CRAWLED

13 hours ago

🤖

ROBOTS ALLOWED

Page Info Filters

Filter	Status	Condition	Details
HTTP status	PASS	`download_http_code = 200`	HTTP 200
Age cutoff	PASS	`download_stamp > now() - 6 MONTH`	0 months ago
History drop	PASS	`isNull(history_drop_reason)`	No drop reason
Spam/ban	PASS	`fh_dont_index != 1 AND ml_spam_score = 0`	ml_spam_score=0
Canonical	PASS	`meta_canonical IS NULL OR = '' OR = src_unparsed`	Not set

Page Details

Property	Value
URL	https://www.php.net/manual/en/features.persistent-connections.php
Last Crawled	2026-04-16 17:52:40 (13 hours ago)
First Indexed	2019-03-25 16:14:43 (7 years ago)
HTTP Status Code	200
Meta Title	PHP: Persistent Database Connections - Manual
Meta Description	Persistent Database Connections
Meta Canonical	null
Boilerpipe Text	What are Persistent Connections? Persistent connections are links that do not close when the execution of your script ends. When a persistent connection is requested, PHP checks if there's already an identical persistent connection (that remained open from earlier) - and if it exists, it uses it. If it does not exist, it creates the link. An 'identical' connection is a connection that was opened to the same host, with the same username and the same password (where applicable). There's no method of requesting a specific connection, or guaranteeing whether you get an existing connection or a brand new one (if all existing connections are in use, or the request is being served by a different worker, which has a separate pool of connections). This means that you cannot use PHP's persistent connections to, for example: assign a specific database session to a specific web user create a large transaction across multiple requests initiate a query on one request and collect the results on another Persistent connections do not give you any functionality that wasn't possible with non-persistent connections. Web Requests There are two ways in which your web server can utilize PHP to generate web pages: The first method is to use PHP as a CGI "wrapper". When run this way, an instance of the PHP interpreter is created and destroyed for every page request (for a PHP page) to your web server. Because it is destroyed after every request, any resources that it acquires (such as a link to an SQL database server) are closed when it is destroyed. In this case, you do not gain anything from trying to use persistent connections - they simply don't persist. The second, and most popular, method is to run PHP-FPM, or PHP as a module in a multiprocess web server, which currently only includes Apache. These setups typically have one process (the parent) which coordinates a set of processes (its children) who actually do the work of serving up web pages. When a request comes in from a client, it is handed off to one of the children that is not already serving another client. This means that when the same client makes a second request to the server, it may be served by a different child process than the first time. When opening a persistent connection, every following page requesting SQL services can reuse the same established connection to the SQL server. Note : You can check which method your web requests use by checking the value of "Server API" in the output of phpinfo() or the value of PHP_SAPI , run from a web request. If the Server API is "Apache 2 Handler" or "FPM/FastCGI", then persistent connections will be used across requests served by the same worker. For any other value, persistent connections will not persist after each request. Command-line Processes As command-line PHP uses a new process for each script, persistent connections are not shared between command-line scripts, so there is no value in using them in transient scripts such as crons or commands. However, they may be useful if, for example, you're writing a long-running application server that serves many requests or tasks and each may need their own database connection. Why Use Them? Persistent connections are good if the overhead to create a link to your SQL server is high. Whether or not this overhead is really high depends on many factors. Like, what kind of database it is, whether or not it sits on the same computer on which your web server sits, how loaded the machine the SQL server sits on is and so forth. The bottom line is that if that connection overhead is high, persistent connections help you considerably. They cause the child process to simply connect only once for its entire lifespan, instead of every time it processes a page that requires connecting to the SQL server. This means that for every child that opened a persistent connection will have its own open persistent connection to the server. For example, if you had 20 different child processes that ran a script that made a persistent connection to your SQL server, you'd have 20 different connections to the SQL server, one from each child. Potential Drawbacks: Connection Limits Note, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous connections, and in the course of a busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), the database with only 16 connections may be rapidly swamped. Persistent connections will usually increase the number of connections open at any given time because idle workers will still hold the connections for the previous requests they served. If a large number of workers is spun up to handle an influx of requests, the connections they opened will remain until the worker is killed or the database server closes the connection. Ensure that the maximum number of connections allowed by the database server is greater than the maximum number of web request workers (plus any other usage such as crons or administrative connections). Check your database documentation for information on handling abandoned or idle connections (timeouts). Long timeouts may significantly increase the number of persistent connections open at any one time. Potential Drawbacks: Maintaining Connection State Some database extensions perform automatic cleanup when the connection is reused; others leave this task at the discretion of the application developer. Depending on the chosen database extension and the application design, manual cleanup may be needed before the script exits. Changes that may leave connections in an unexpected state include: Selected / default database Table locks Uncommitted transactions Temporary tables Connection specific settings or features such as profiling Table locks and transactions that are not cleaned up or closed may cause other queries to be blocked indefinitely and/or cause subsequent reuse of the connection to cause unexpected changes. Having the wrong database selected will cause subsequent reuse of the connection to be unable to execute queries as expected (or execute them on the wrong database if schemas are similar enough). If temporary tables are not cleaned up, subsequent requests will not be able to recreate the same table. You can implement cleanup using class destructors or register_shutdown_function() . You may also want to consider dedicated connection pooling proxies that include this as part of their functionality. Final Words Given their behavior and potential drawbacks described above, you should not use persistent connections without careful consideration. They should not be used without implementing additional changes to your application and careful configuration of your database server and web server and/or PHP-FPM. Consider alternative solutions such as investigating and fixing the causes of connection creation overheads (for example, disabling reverse DNS lookups on the database server), or dedicated connection pooling proxies. For high volume web APIs, consider using alternative runtimes or long-running application servers. See Also ibase_pconnect() oci_pconnect() odbc_pconnect() pfsockopen() pg_connect() MySQLi and Persistent Connections PDO Connection Management 22 Tom ¶ 16 years ago There's a third case for PHP: run on a fastCGI interface. In this case, PHP processes are NOT destroyed after each request, and so persistent connections do persist. Set PHP_FCGI_CHILDREN << mysql's max_connections and you'll be fine. 14 ambrish at php dot net ¶ 15 years ago In IBM_DB2 extension v1.9.0 or later performs a transaction rollback on persistent connections at the end of a request, thus ending the transaction. This prevents the transaction block from carrying over to the next request which uses that connection if script execution ends before the transaction block does. 14 php at alfadog dot net ¶ 12 years ago One additional not regarding odbc_pconnect and possibly other variations of pconnect: If the connection encounters an error (bad SQL, incorrect request, etc), that error will return with be present in odbc_errormsg for every subsequent action on that connection, even if subsequent actions don't cause another error. For example: A script connects with odbc_pconnect. The connection is created on it's first use. The script calls a query "Select * FROM Table1". Table1 doesn't exist and odbc_errormsg contains that error. Later(days, perhaps), a different script is called using the same parameters to odbc_pconnect. The connection already exists, to it is reused. The script calls a query "Select * FROM Table0". The query runs fine, but odbc_errormsg still returns the error about Table1 not existing. I'm not seeing a way to clear that error using odbc_ functions, so keep your eyes open for this gotcha or use odbc_connect instead. 14 christopher dot jones at oracle dot com ¶ 18 years ago For the oci8 extension it is not true that " [...] when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does.". The oci8 extension does a rollback at the end scripts using persistent connections, thus ending the transaction. The rollback also releases locks. However any ALTER SESSION command (e.g. changing the date format) on a persistent connection will be retained over to the next script. 11 ynzhang from lakeheadu canada ¶ 17 years ago It seems that using pg_pconnect() will not persist the temporary views/tables. So if you are trying to create temporary views/tables with the query results and then access them with the next script of the same session, you are out of luck. Those temporary view/tables are gone after each PHP script ended. One way to get around this problem is to create real view/table with session ID as part of the name and record the name&creation time in a common table. Have a garbage collection script to drop the view/table who's session is expired. 10 jean_christian at myrealbox dot com ¶ 23 years ago If anyone ever wonders why the number of idle db process (open connections) seems to grow even though you are using persistent connections, here's why: "You are probably using a multi-process web server such as Apache. Since database connections cannot be shared among different processes a new one is created if the request happen to come to a different web server child process." 8 andy at paradigm-reborn dot com ¶ 19 years ago To those using MySQL and finding a lot of leftover sleeping processes, take a look at MySQL's wait_timeout directive. By default it is set to 8 hours, but almost any decent production server will have been lowered to the 60 second range. Even on my testing server, I was having problems with too many connections from leftover persistent connections.
Markdown	[update page now](https://www.php.net/x-myracloud-5958a2bbbed300a9b9ac631223924e0b/1776361960.371) [![](https://www.php.net/images/logos/php-logo-white.svg)](https://www.php.net/) - [Downloads](https://www.php.net/downloads.php) - [Documentation](https://www.php.net/docs.php) - [Get Involved](https://www.php.net/get-involved.php) - [Help](https://www.php.net/support.php) - [![PHP 8.5](https://www.php.net/images/php8/logo_php8_5.svg)](https://www.php.net/releases/8.5/index.php) Search docs [Getting Started](https://www.php.net/manual/en/getting-started.php) [Introduction](https://www.php.net/manual/en/introduction.php) [A simple tutorial](https://www.php.net/manual/en/tutorial.php) [Language Reference](https://www.php.net/manual/en/langref.php) [Basic syntax](https://www.php.net/manual/en/language.basic-syntax.php) [Types](https://www.php.net/manual/en/language.types.php) [Variables](https://www.php.net/manual/en/language.variables.php) [Constants](https://www.php.net/manual/en/language.constants.php) [Expressions](https://www.php.net/manual/en/language.expressions.php) [Operators](https://www.php.net/manual/en/language.operators.php) [Control Structures](https://www.php.net/manual/en/language.control-structures.php) [Functions](https://www.php.net/manual/en/language.functions.php) [Classes and Objects](https://www.php.net/manual/en/language.oop5.php) [Namespaces](https://www.php.net/manual/en/language.namespaces.php) [Enumerations](https://www.php.net/manual/en/language.enumerations.php) [Errors](https://www.php.net/manual/en/language.errors.php) [Exceptions](https://www.php.net/manual/en/language.exceptions.php) [Fibers](https://www.php.net/manual/en/language.fibers.php) [Generators](https://www.php.net/manual/en/language.generators.php) [Attributes](https://www.php.net/manual/en/language.attributes.php) [References Explained](https://www.php.net/manual/en/language.references.php) [Predefined Variables](https://www.php.net/manual/en/reserved.variables.php) [Predefined Exceptions](https://www.php.net/manual/en/reserved.exceptions.php) [Predefined Interfaces and Classes](https://www.php.net/manual/en/reserved.interfaces.php) [Predefined Attributes](https://www.php.net/manual/en/reserved.attributes.php) [Context options and parameters](https://www.php.net/manual/en/context.php) [Supported Protocols and Wrappers](https://www.php.net/manual/en/wrappers.php) [Security](https://www.php.net/manual/en/security.php) [Introduction](https://www.php.net/manual/en/security.intro.php) [General considerations](https://www.php.net/manual/en/security.general.php) [Installed as CGI binary](https://www.php.net/manual/en/security.cgi-bin.php) [Installed as an Apache module](https://www.php.net/manual/en/security.apache.php) [Session Security](https://www.php.net/manual/en/security.sessions.php) [Filesystem Security](https://www.php.net/manual/en/security.filesystem.php) [Database Security](https://www.php.net/manual/en/security.database.php) [Error Reporting](https://www.php.net/manual/en/security.errors.php) [User Submitted Data](https://www.php.net/manual/en/security.variables.php) [Hiding PHP](https://www.php.net/manual/en/security.hiding.php) [Keeping Current](https://www.php.net/manual/en/security.current.php) [Features](https://www.php.net/manual/en/features.php) [HTTP authentication with PHP](https://www.php.net/manual/en/features.http-auth.php) [Cookies](https://www.php.net/manual/en/features.cookies.php) [Sessions](https://www.php.net/manual/en/features.sessions.php) [Handling file uploads](https://www.php.net/manual/en/features.file-upload.php) [Using remote files](https://www.php.net/manual/en/features.remote-files.php) [Connection handling](https://www.php.net/manual/en/features.connection-handling.php) [Persistent Database Connections](https://www.php.net/manual/en/features.persistent-connections.php) [Command line usage](https://www.php.net/manual/en/features.commandline.php) [Garbage Collection](https://www.php.net/manual/en/features.gc.php) [DTrace Dynamic Tracing](https://www.php.net/manual/en/features.dtrace.php) [Function Reference](https://www.php.net/manual/en/funcref.php) [Affecting PHP's Behaviour](https://www.php.net/manual/en/refs.basic.php.php) [Audio Formats Manipulation](https://www.php.net/manual/en/refs.utilspec.audio.php) [Authentication Services](https://www.php.net/manual/en/refs.remote.auth.php) [Command Line Specific Extensions](https://www.php.net/manual/en/refs.utilspec.cmdline.php) [Compression and Archive Extensions](https://www.php.net/manual/en/refs.compression.php) [Cryptography Extensions](https://www.php.net/manual/en/refs.crypto.php) [Database Extensions](https://www.php.net/manual/en/refs.database.php) [Date and Time Related Extensions](https://www.php.net/manual/en/refs.calendar.php) [File System Related Extensions](https://www.php.net/manual/en/refs.fileprocess.file.php) [Human Language and Character Encoding Support](https://www.php.net/manual/en/refs.international.php) [Image Processing and Generation](https://www.php.net/manual/en/refs.utilspec.image.php) [Mail Related Extensions](https://www.php.net/manual/en/refs.remote.mail.php) [Mathematical Extensions](https://www.php.net/manual/en/refs.math.php) [Non-Text MIME Output](https://www.php.net/manual/en/refs.utilspec.nontext.php) [Process Control Extensions](https://www.php.net/manual/en/refs.fileprocess.process.php) [Other Basic Extensions](https://www.php.net/manual/en/refs.basic.other.php) [Other Services](https://www.php.net/manual/en/refs.remote.other.php) [Search Engine Extensions](https://www.php.net/manual/en/refs.search.php) [Server Specific Extensions](https://www.php.net/manual/en/refs.utilspec.server.php) [Session Extensions](https://www.php.net/manual/en/refs.basic.session.php) [Text Processing](https://www.php.net/manual/en/refs.basic.text.php) [Variable and Type Related Extensions](https://www.php.net/manual/en/refs.basic.vartype.php) [Web Services](https://www.php.net/manual/en/refs.webservice.php) [Windows Only Extensions](https://www.php.net/manual/en/refs.utilspec.windows.php) [XML Manipulation](https://www.php.net/manual/en/refs.xml.php) [GUI Extensions](https://www.php.net/manual/en/refs.ui.php) Keyboard Shortcuts ? This help j Next menu item k Previous menu item g p Previous man page g n Next man page G Scroll to bottom g g Scroll to top g h Goto homepage g s Goto search (current page) / Focus search box [Command line usage »](https://www.php.net/manual/en/features.commandline.php) [« Connection handling](https://www.php.net/manual/en/features.connection-handling.php) - [Preface](https://www.php.net/manual/en/index.php) - [Features](https://www.php.net/manual/en/features.php) # Persistent Database Connections ### What are Persistent Connections? Persistent connections are links that do not close when the execution of your script ends. When a persistent connection is requested, PHP checks if there's already an identical persistent connection (that remained open from earlier) - and if it exists, it uses it. If it does not exist, it creates the link. An 'identical' connection is a connection that was opened to the same host, with the same username and the same password (where applicable). There's no method of requesting a specific connection, or guaranteeing whether you get an existing connection or a brand new one (if all existing connections are in use, or the request is being served by a different worker, which has a separate pool of connections). This means that you cannot use PHP's persistent connections to, for example: - assign a specific database session to a specific web user - create a large transaction across multiple requests - initiate a query on one request and collect the results on another Persistent connections do not give you any functionality that wasn't possible with non-persistent connections. ### Web Requests There are two ways in which your web server can utilize PHP to generate web pages: The first method is to use PHP as a CGI "wrapper". When run this way, an instance of the PHP interpreter is created and destroyed for every page request (for a PHP page) to your web server. Because it is destroyed after every request, any resources that it acquires (such as a link to an SQL database server) are closed when it is destroyed. In this case, you do not gain anything from trying to use persistent connections - they simply don't persist. The second, and most popular, method is to run PHP-FPM, or PHP as a module in a multiprocess web server, which currently only includes Apache. These setups typically have one process (the parent) which coordinates a set of processes (its children) who actually do the work of serving up web pages. When a request comes in from a client, it is handed off to one of the children that is not already serving another client. This means that when the same client makes a second request to the server, it may be served by a different child process than the first time. When opening a persistent connection, every following page requesting SQL services can reuse the same established connection to the SQL server. > Note: > > You can check which method your web requests use by checking the value of "Server API" in the output of [phpinfo()](https://www.php.net/manual/en/function.phpinfo.php) or the value of `PHP_SAPI`, run from a web request. > > If the Server API is "Apache 2 Handler" or "FPM/FastCGI", then persistent connections will be used across requests served by the same worker. For any other value, persistent connections will not persist after each request. ### Command-line Processes As command-line PHP uses a new process for each script, persistent connections are not shared between command-line scripts, so there is no value in using them in transient scripts such as crons or commands. However, they may be useful if, for example, you're writing a long-running application server that serves many requests or tasks and each may need their own database connection. ### Why Use Them? Persistent connections are good if the overhead to create a link to your SQL server is high. Whether or not this overhead is really high depends on many factors. Like, what kind of database it is, whether or not it sits on the same computer on which your web server sits, how loaded the machine the SQL server sits on is and so forth. The bottom line is that if that connection overhead is high, persistent connections help you considerably. They cause the child process to simply connect only once for its entire lifespan, instead of every time it processes a page that requires connecting to the SQL server. This means that for every child that opened a persistent connection will have its own open persistent connection to the server. For example, if you had 20 different child processes that ran a script that made a persistent connection to your SQL server, you'd have 20 different connections to the SQL server, one from each child. ### Potential Drawbacks: Connection Limits Note, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous connections, and in the course of a busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), the database with only 16 connections may be rapidly swamped. Persistent connections will usually increase the number of connections open at any given time because idle workers will still hold the connections for the previous requests they served. If a large number of workers is spun up to handle an influx of requests, the connections they opened will remain until the worker is killed or the database server closes the connection. Ensure that the maximum number of connections allowed by the database server is greater than the maximum number of web request workers (plus any other usage such as crons or administrative connections). Check your database documentation for information on handling abandoned or idle connections (timeouts). Long timeouts may significantly increase the number of persistent connections open at any one time. ### Potential Drawbacks: Maintaining Connection State Some database extensions perform automatic cleanup when the connection is reused; others leave this task at the discretion of the application developer. Depending on the chosen database extension and the application design, manual cleanup may be needed before the script exits. Changes that may leave connections in an unexpected state include: - Selected / default database - Table locks - Uncommitted transactions - Temporary tables - Connection specific settings or features such as profiling Table locks and transactions that are not cleaned up or closed may cause other queries to be blocked indefinitely and/or cause subsequent reuse of the connection to cause unexpected changes. Having the wrong database selected will cause subsequent reuse of the connection to be unable to execute queries as expected (or execute them on the wrong database if schemas are similar enough). If temporary tables are not cleaned up, subsequent requests will not be able to recreate the same table. You can implement cleanup using class destructors or [register\_shutdown\_function()](https://www.php.net/manual/en/function.register-shutdown-function.php). You may also want to consider dedicated connection pooling proxies that include this as part of their functionality. ### Final Words Given their behavior and potential drawbacks described above, you should not use persistent connections without careful consideration. They should not be used without implementing additional changes to your application and careful configuration of your database server and web server and/or PHP-FPM. Consider alternative solutions such as investigating and fixing the causes of connection creation overheads (for example, disabling reverse DNS lookups on the database server), or dedicated connection pooling proxies. For high volume web APIs, consider using alternative runtimes or long-running application servers. ### See Also - [ibase\_pconnect()](https://www.php.net/manual/en/function.ibase-pconnect.php) - [oci\_pconnect()](https://www.php.net/manual/en/function.oci-pconnect.php) - [odbc\_pconnect()](https://www.php.net/manual/en/function.odbc-pconnect.php) - [pfsockopen()](https://www.php.net/manual/en/function.pfsockopen.php) - [pg\_connect()](https://www.php.net/manual/en/function.pg-connect.php) - [MySQLi and Persistent Connections](https://www.php.net/manual/en/mysqli.persistconns.php) - [PDO Connection Management](https://www.php.net/manual/en/pdo.connections.php) ### Found A Problem? [Learn How To Improve This Page](https://github.com/php/doc-base/blob/master/README.md "This will take you to our contribution guidelines on GitHub") • [Submit a Pull Request](https://github.com/php/doc-en/blob/master/features/persistent-connections.xml) • [Report a Bug](https://github.com/php/doc-en/issues/new?body=From%20manual%20page:%20https:%2F%2Fphp.net%2Ffeatures.persistent-connections%0A%0A---) [＋add a note](https://www.php.net/manual/add-note.php?sect=features.persistent-connections&repo=en&redirect=https://www.php.net/manual/en/features.persistent-connections.php) ### User Contributed Notes 7 notes [up](https://www.php.net/manual/vote-note.php?id=95340&page=features.persistent-connections&vote=up "Vote up!") [down](https://www.php.net/manual/vote-note.php?id=95340&page=features.persistent-connections&vote=down "Vote down!") 22 [*Tom](https://www.php.net/manual/en/features.persistent-connections.php#95340) [¶](https://www.php.net/manual/en/features.persistent-connections.php#95340) 16 years ago* ``` There's a third case for PHP: run on a fastCGI interface. In this case, PHP processes are NOT destroyed after each request, and so persistent connections do persist. Set PHP_FCGI_CHILDREN << mysql's max_connections and you'll be fine. ``` [up](https://www.php.net/manual/vote-note.php?id=100009&page=features.persistent-connections&vote=up "Vote up!") [down](https://www.php.net/manual/vote-note.php?id=100009&page=features.persistent-connections&vote=down "Vote down!") 14 [*ambrish at php dot net](https://www.php.net/manual/en/features.persistent-connections.php#100009) [¶](https://www.php.net/manual/en/features.persistent-connections.php#100009) 15 years ago* ``` In IBM_DB2 extension v1.9.0 or later performs a transaction rollback on persistent connections at the end of a request, thus ending the transaction. This prevents the transaction block from carrying over to the next request which uses that connection if script execution ends before the transaction block does. ``` [up](https://www.php.net/manual/vote-note.php?id=114190&page=features.persistent-connections&vote=up "Vote up!") [down](https://www.php.net/manual/vote-note.php?id=114190&page=features.persistent-connections&vote=down "Vote down!") 14 [*php at alfadog dot net](https://www.php.net/manual/en/features.persistent-connections.php#114190) [¶](https://www.php.net/manual/en/features.persistent-connections.php#114190) 12 years ago* ``` One additional not regarding odbc_pconnect and possibly other variations of pconnect: If the connection encounters an error (bad SQL, incorrect request, etc), that error will return with be present in odbc_errormsg for every subsequent action on that connection, even if subsequent actions don't cause another error. For example: A script connects with odbc_pconnect. The connection is created on it's first use. The script calls a query "Select * FROM Table1". Table1 doesn't exist and odbc_errormsg contains that error. Later(days, perhaps), a different script is called using the same parameters to odbc_pconnect. The connection already exists, to it is reused. The script calls a query "Select * FROM Table0". The query runs fine, but odbc_errormsg still returns the error about Table1 not existing. I'm not seeing a way to clear that error using odbc_ functions, so keep your eyes open for this gotcha or use odbc_connect instead. ``` [up](https://www.php.net/manual/vote-note.php?id=76013&page=features.persistent-connections&vote=up "Vote up!") [down](https://www.php.net/manual/vote-note.php?id=76013&page=features.persistent-connections&vote=down "Vote down!") 14 [*christopher dot jones at oracle dot com](https://www.php.net/manual/en/features.persistent-connections.php#76013) [¶](https://www.php.net/manual/en/features.persistent-connections.php#76013) 18 years ago* ``` For the oci8 extension it is not true that " [...] when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does.". The oci8 extension does a rollback at the end scripts using persistent connections, thus ending the transaction. The rollback also releases locks. However any ALTER SESSION command (e.g. changing the date format) on a persistent connection will be retained over to the next script. ``` [up](https://www.php.net/manual/vote-note.php?id=89465&page=features.persistent-connections&vote=up "Vote up!") [down](https://www.php.net/manual/vote-note.php?id=89465&page=features.persistent-connections&vote=down "Vote down!") 11 [*ynzhang from lakeheadu canada](https://www.php.net/manual/en/features.persistent-connections.php#89465) [¶](https://www.php.net/manual/en/features.persistent-connections.php#89465) 17 years ago* ``` It seems that using pg_pconnect() will not persist the temporary views/tables. So if you are trying to create temporary views/tables with the query results and then access them with the next script of the same session, you are out of luck. Those temporary view/tables are gone after each PHP script ended. One way to get around this problem is to create real view/table with session ID as part of the name and record the name&creation time in a common table. Have a garbage collection script to drop the view/table who's session is expired. ``` [up](https://www.php.net/manual/vote-note.php?id=24393&page=features.persistent-connections&vote=up "Vote up!") [down](https://www.php.net/manual/vote-note.php?id=24393&page=features.persistent-connections&vote=down "Vote down!") 10 [*jean\_christian at myrealbox dot com](https://www.php.net/manual/en/features.persistent-connections.php#24393) [¶](https://www.php.net/manual/en/features.persistent-connections.php#24393) 23 years ago* ``` If anyone ever wonders why the number of idle db process (open connections) seems to grow even though you are using persistent connections, here's why: "You are probably using a multi-process web server such as Apache. Since database connections cannot be shared among different processes a new one is created if the request happen to come to a different web server child process." ``` [up](https://www.php.net/manual/vote-note.php?id=73370&page=features.persistent-connections&vote=up "Vote up!") [down](https://www.php.net/manual/vote-note.php?id=73370&page=features.persistent-connections&vote=down "Vote down!") 8 [*andy at paradigm-reborn dot com](https://www.php.net/manual/en/features.persistent-connections.php#73370) [¶](https://www.php.net/manual/en/features.persistent-connections.php#73370) 19 years ago* ``` To those using MySQL and finding a lot of leftover sleeping processes, take a look at MySQL's wait_timeout directive. By default it is set to 8 hours, but almost any decent production server will have been lowered to the 60 second range. Even on my testing server, I was having problems with too many connections from leftover persistent connections. ``` [＋add a note](https://www.php.net/manual/add-note.php?sect=features.persistent-connections&repo=en&redirect=https://www.php.net/manual/en/features.persistent-connections.php) - [Features](https://www.php.net/manual/en/features.php) - [HTTP authentication with PHP](https://www.php.net/manual/en/features.http-auth.php "HTTP authentication with PHP") - [Cookies](https://www.php.net/manual/en/features.cookies.php "Cookies") - [Sessions](https://www.php.net/manual/en/features.sessions.php "Sessions") - [Handling file uploads](https://www.php.net/manual/en/features.file-upload.php "Handling file uploads") - [Using remote files](https://www.php.net/manual/en/features.remote-files.php "Using remote files") - [Connection handling](https://www.php.net/manual/en/features.connection-handling.php "Connection handling") - [Persistent Database Connections](https://www.php.net/manual/en/features.persistent-connections.php "Persistent Database Connections") - [Command line usage](https://www.php.net/manual/en/features.commandline.php "Command line usage") - [Garbage Collection](https://www.php.net/manual/en/features.gc.php "Garbage Collection") - [DTrace Dynamic Tracing](https://www.php.net/manual/en/features.dtrace.php "DTrace Dynamic Tracing") - [Copyright © 2001-2026 The PHP Documentation Group](https://www.php.net/manual/en/copyright.php) - [My PHP.net](https://www.php.net/my.php) - [Contact](https://www.php.net/contact.php) - [Other PHP.net sites](https://www.php.net/sites.php) - [Privacy policy](https://www.php.net/privacy.php) [![To Top](https://www.php.net/images/to-top@2x.png)]() `↑` and `↓` to navigate • `Enter` to select • `Esc` to close • `/` to open Press `Enter` without selection to search using Google
Readable Markdown	### What are Persistent Connections? Persistent connections are links that do not close when the execution of your script ends. When a persistent connection is requested, PHP checks if there's already an identical persistent connection (that remained open from earlier) - and if it exists, it uses it. If it does not exist, it creates the link. An 'identical' connection is a connection that was opened to the same host, with the same username and the same password (where applicable). There's no method of requesting a specific connection, or guaranteeing whether you get an existing connection or a brand new one (if all existing connections are in use, or the request is being served by a different worker, which has a separate pool of connections). This means that you cannot use PHP's persistent connections to, for example: - assign a specific database session to a specific web user - create a large transaction across multiple requests - initiate a query on one request and collect the results on another Persistent connections do not give you any functionality that wasn't possible with non-persistent connections. ### Web Requests There are two ways in which your web server can utilize PHP to generate web pages: The first method is to use PHP as a CGI "wrapper". When run this way, an instance of the PHP interpreter is created and destroyed for every page request (for a PHP page) to your web server. Because it is destroyed after every request, any resources that it acquires (such as a link to an SQL database server) are closed when it is destroyed. In this case, you do not gain anything from trying to use persistent connections - they simply don't persist. The second, and most popular, method is to run PHP-FPM, or PHP as a module in a multiprocess web server, which currently only includes Apache. These setups typically have one process (the parent) which coordinates a set of processes (its children) who actually do the work of serving up web pages. When a request comes in from a client, it is handed off to one of the children that is not already serving another client. This means that when the same client makes a second request to the server, it may be served by a different child process than the first time. When opening a persistent connection, every following page requesting SQL services can reuse the same established connection to the SQL server. > Note: > > You can check which method your web requests use by checking the value of "Server API" in the output of [phpinfo()](https://www.php.net/manual/en/function.phpinfo.php) or the value of `PHP_SAPI`, run from a web request. > > If the Server API is "Apache 2 Handler" or "FPM/FastCGI", then persistent connections will be used across requests served by the same worker. For any other value, persistent connections will not persist after each request. ### Command-line Processes As command-line PHP uses a new process for each script, persistent connections are not shared between command-line scripts, so there is no value in using them in transient scripts such as crons or commands. However, they may be useful if, for example, you're writing a long-running application server that serves many requests or tasks and each may need their own database connection. ### Why Use Them? Persistent connections are good if the overhead to create a link to your SQL server is high. Whether or not this overhead is really high depends on many factors. Like, what kind of database it is, whether or not it sits on the same computer on which your web server sits, how loaded the machine the SQL server sits on is and so forth. The bottom line is that if that connection overhead is high, persistent connections help you considerably. They cause the child process to simply connect only once for its entire lifespan, instead of every time it processes a page that requires connecting to the SQL server. This means that for every child that opened a persistent connection will have its own open persistent connection to the server. For example, if you had 20 different child processes that ran a script that made a persistent connection to your SQL server, you'd have 20 different connections to the SQL server, one from each child. ### Potential Drawbacks: Connection Limits Note, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous connections, and in the course of a busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), the database with only 16 connections may be rapidly swamped. Persistent connections will usually increase the number of connections open at any given time because idle workers will still hold the connections for the previous requests they served. If a large number of workers is spun up to handle an influx of requests, the connections they opened will remain until the worker is killed or the database server closes the connection. Ensure that the maximum number of connections allowed by the database server is greater than the maximum number of web request workers (plus any other usage such as crons or administrative connections). Check your database documentation for information on handling abandoned or idle connections (timeouts). Long timeouts may significantly increase the number of persistent connections open at any one time. ### Potential Drawbacks: Maintaining Connection State Some database extensions perform automatic cleanup when the connection is reused; others leave this task at the discretion of the application developer. Depending on the chosen database extension and the application design, manual cleanup may be needed before the script exits. Changes that may leave connections in an unexpected state include: - Selected / default database - Table locks - Uncommitted transactions - Temporary tables - Connection specific settings or features such as profiling Table locks and transactions that are not cleaned up or closed may cause other queries to be blocked indefinitely and/or cause subsequent reuse of the connection to cause unexpected changes. Having the wrong database selected will cause subsequent reuse of the connection to be unable to execute queries as expected (or execute them on the wrong database if schemas are similar enough). If temporary tables are not cleaned up, subsequent requests will not be able to recreate the same table. You can implement cleanup using class destructors or [register\_shutdown\_function()](https://www.php.net/manual/en/function.register-shutdown-function.php). You may also want to consider dedicated connection pooling proxies that include this as part of their functionality. ### Final Words Given their behavior and potential drawbacks described above, you should not use persistent connections without careful consideration. They should not be used without implementing additional changes to your application and careful configuration of your database server and web server and/or PHP-FPM. Consider alternative solutions such as investigating and fixing the causes of connection creation overheads (for example, disabling reverse DNS lookups on the database server), or dedicated connection pooling proxies. For high volume web APIs, consider using alternative runtimes or long-running application servers. ### See Also - [ibase\_pconnect()](https://www.php.net/manual/en/function.ibase-pconnect.php) - [oci\_pconnect()](https://www.php.net/manual/en/function.oci-pconnect.php) - [odbc\_pconnect()](https://www.php.net/manual/en/function.odbc-pconnect.php) - [pfsockopen()](https://www.php.net/manual/en/function.pfsockopen.php) - [pg\_connect()](https://www.php.net/manual/en/function.pg-connect.php) - [MySQLi and Persistent Connections](https://www.php.net/manual/en/mysqli.persistconns.php) - [PDO Connection Management](https://www.php.net/manual/en/pdo.connections.php) 22 [*Tom](https://www.php.net/manual/en/features.persistent-connections.php#95340) [¶](https://www.php.net/manual/en/features.persistent-connections.php#95340) 16 years ago* ``` There's a third case for PHP: run on a fastCGI interface. In this case, PHP processes are NOT destroyed after each request, and so persistent connections do persist. Set PHP_FCGI_CHILDREN << mysql's max_connections and you'll be fine. ``` 14 [*ambrish at php dot net](https://www.php.net/manual/en/features.persistent-connections.php#100009) [¶](https://www.php.net/manual/en/features.persistent-connections.php#100009) 15 years ago* ``` In IBM_DB2 extension v1.9.0 or later performs a transaction rollback on persistent connections at the end of a request, thus ending the transaction. This prevents the transaction block from carrying over to the next request which uses that connection if script execution ends before the transaction block does. ``` 14 [*php at alfadog dot net](https://www.php.net/manual/en/features.persistent-connections.php#114190) [¶](https://www.php.net/manual/en/features.persistent-connections.php#114190) 12 years ago* ``` One additional not regarding odbc_pconnect and possibly other variations of pconnect: If the connection encounters an error (bad SQL, incorrect request, etc), that error will return with be present in odbc_errormsg for every subsequent action on that connection, even if subsequent actions don't cause another error. For example: A script connects with odbc_pconnect. The connection is created on it's first use. The script calls a query "Select * FROM Table1". Table1 doesn't exist and odbc_errormsg contains that error. Later(days, perhaps), a different script is called using the same parameters to odbc_pconnect. The connection already exists, to it is reused. The script calls a query "Select * FROM Table0". The query runs fine, but odbc_errormsg still returns the error about Table1 not existing. I'm not seeing a way to clear that error using odbc_ functions, so keep your eyes open for this gotcha or use odbc_connect instead. ``` 14 [*christopher dot jones at oracle dot com](https://www.php.net/manual/en/features.persistent-connections.php#76013) [¶](https://www.php.net/manual/en/features.persistent-connections.php#76013) 18 years ago* ``` For the oci8 extension it is not true that " [...] when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does.". The oci8 extension does a rollback at the end scripts using persistent connections, thus ending the transaction. The rollback also releases locks. However any ALTER SESSION command (e.g. changing the date format) on a persistent connection will be retained over to the next script. ``` 11 [*ynzhang from lakeheadu canada](https://www.php.net/manual/en/features.persistent-connections.php#89465) [¶](https://www.php.net/manual/en/features.persistent-connections.php#89465) 17 years ago* ``` It seems that using pg_pconnect() will not persist the temporary views/tables. So if you are trying to create temporary views/tables with the query results and then access them with the next script of the same session, you are out of luck. Those temporary view/tables are gone after each PHP script ended. One way to get around this problem is to create real view/table with session ID as part of the name and record the name&creation time in a common table. Have a garbage collection script to drop the view/table who's session is expired. ``` 10 [*jean\_christian at myrealbox dot com](https://www.php.net/manual/en/features.persistent-connections.php#24393) [¶](https://www.php.net/manual/en/features.persistent-connections.php#24393) 23 years ago* ``` If anyone ever wonders why the number of idle db process (open connections) seems to grow even though you are using persistent connections, here's why: "You are probably using a multi-process web server such as Apache. Since database connections cannot be shared among different processes a new one is created if the request happen to come to a different web server child process." ``` 8 [*andy at paradigm-reborn dot com](https://www.php.net/manual/en/features.persistent-connections.php#73370) [¶](https://www.php.net/manual/en/features.persistent-connections.php#73370) 19 years ago* ``` To those using MySQL and finding a lot of leftover sleeping processes, take a look at MySQL's wait_timeout directive. By default it is set to 8 hours, but almost any decent production server will have been lowered to the 60 second range. Even on my testing server, I was having problems with too many connections from leftover persistent connections. ```
Shard	91 (laksa)
Root Hash	2869005436169329891
Unparsed URL	net,php!www,/manual/en/features.persistent-connections.php s443