Mysql_pconnect() と mysql_connect() は非常に似ていますが、主な違いが 2 つあります。
まず、この関数は、接続するときに、同じホスト上で同じユーザー名とパスワードで開かれている (永続的な) 接続を検索します。見つかった場合は、新しい接続を開かずにこの接続 ID を返します。
次に、スクリプトの実行時に SQL サーバーへの接続は閉じられず、この接続は将来の使用のために開いたままになります (mysql_close() は、mysql_pconnect() によって確立された接続を閉じません)。
永続的なデータベース接続は、スクリプトの実行が終了しても閉じられない接続です。常設接続の要求を受信したとき。 PHP は、(以前に開かれた) 同一の永続接続が既に存在するかどうかを確認します。存在する場合は接続が直接使用され、存在しない場合は新しい接続が確立されます。いわゆる「同じ」接続とは、同じユーザー名とパスワードを使用した同じホストへの接続を指します。
Web サーバーの動作と分散負荷を完全に理解していない読者は、永続的な接続の役割を誤解する可能性があります。特に、永続的な接続は、同じ接続上で「ユーザー セッション」を確立する機能を提供せず、トランザクションを効果的に確立する機能も提供しません。実際、厳密に言えば、永続接続には、非永続接続が提供しない特別な機能はありません。
なぜですか?
これは、Web サーバーの動作方法に関係しています。 Web サーバーが PHP を使用して Web ページを生成できる方法は 3 つあります。
最初の方法は、PHP を「シェル」として使用することです。この方法で実行すると、PHP は Web サーバーに対して行われた PHP ページ要求ごとに PHP インタープリタ スレッドを生成および終了します。このスレッドは各リクエストの終了とともに終了するため、このスレッドで使用されているリソース (SQL データベース サーバーへの接続など) はスレッドの終了とともに閉じられます。この場合、永続的な接続を使用しても何も変わりません。永続的な接続がまったくないためです。
2 番目の最も一般的な方法は、PHP をマルチプロセス Web サーバーのモジュールとして使用することです。この方法は現在 Apache でのみ機能します。マルチプロセス サーバーの一般的な特徴は、親プロセスと子プロセスのグループが連携して実行され、その中で実際に Web ページを生成するのは子プロセスであることです。クライアントが親プロセスにリクエストを行うと、そのリクエストは他のクライアント リクエストによって占有されていない子プロセスに渡されます。これは、同じクライアントがサーバーに 2 度目にリクエストを行うと、そのリクエストが別の子プロセスによって処理される可能性があることを意味します。永続的な接続を開いた後は、SQL サービスを要求する後続のすべてのページで、確立された SQL Server 接続を再利用できます。
最後の方法は、PHP をマルチスレッド Web サーバーのプラグインとして使用することです。現在、PHP 4 はすでに ISAPI、WSAPI、NSAPI (Windows 環境下) をサポートしているため、PHP を Netscape FastTrack (iPlanet)、Microsoft の Internet Information Server (IIS)、O'Reilly の WebSite Pro などのマルチスレッド Web サーバーとして使用できます。 .プラグイン。永続的な接続の動作は、前述のマルチプロセス モデルと基本的に同じです。 PHP 3 は SAPI をサポートしていないことに注意してください。
永続接続に追加機能がない場合、それを使用する利点は何ですか?
答えは非常に簡単です - 効率です。クライアントからの SQL サーバーへの接続要求が非常に頻繁に行われる場合、永続的な接続の方が効率的です。頻繁な接続要求の基準は、多くの要因によって異なります。たとえば、データベースの種類、データベース サービスと Web サービスが同じサーバー上にあるかどうか、SQL サーバーの負荷のかかり方などです。しかし、接続要求が頻繁に発生する場合、永続的な接続によって効率が大幅に向上することは少なくともわかっています。これにより、各子プロセスは、ページが処理されるたびに SQL サーバーへの接続要求を行うのではなく、ライフ サイクル内で 1 つの接続操作のみを実行できるようになります。これは、各子プロセスがサーバーへの独自の独立した永続的な接続を確立することを意味します。たとえば、20 の異なる子プロセスが SQL サーバーへの永続接続を確立するスクリプトを実行する場合、実際には SQL サーバーに対して 20 の異なる永続接続がプロセスごとに 1 つずつ確立されます。
永続的に接続されている子プロセスの数が、設定されたデータベース接続制限を超えると、システムで何らかの不具合が発生することに注意してください。データベースの同時接続数が 16 に制限されており、ビジー セッションの場合に 17 のスレッドが接続を試行すると、1 つのスレッドが接続に失敗します。この時点で、接続を閉じることを妨げるエラー (無限ループなど) がスクリプト内で発生すると、データベースへの 16 個の接続がすぐに影響を受けます。放棄された接続とアイドル状態の接続を処理する方法については、使用しているデータベースのドキュメントを参照してください。 www.2cto.com
警告
永続的な接続を使用する場合には、注意すべき特別な問題がいくつかあります。たとえば、永続接続でテーブル ロックを使用する場合、何らかの理由でスクリプトがテーブル ロックを解放できない場合、同じ接続を使用する後続のスクリプトは永続的にブロックされ、httpd サービスまたはデータベース サービスの再起動が必要になります。また、トランザクション処理を使用する場合、トランザクションブロッキングが発生する前にスクリプトが終了すると、同じコネクションを使用する次のスクリプトにもブロッキングが影響します。状況に関係なく、 register_shutdown_function() 関数を使用して、テーブル ロックを開いたり、トランザクションをロールバックしたりするための単純なクリーンアップ関数を登録できます。あるいは、より良い方法は、データ テーブル ロックやトランザクション処理を使用するスクリプトで永続接続を使用しないことです。これにより、この問題を根本的に解決できます (もちろん、他の場所で永続接続を使用することもできます)。
以下は重要な要約です。永続的な接続は、一般的な接続に対して 1 対 1 の分散を確立するように設計されています。これは、永続的な接続を非永続的な接続に置き換えるときに、スクリプトの動作が変わらないことを保証できなければならないことを意味します。永続的な接続を使用すると、(非常に) スクリプトの効率が変わりますが、スクリプトの動作は変わりません。
著者: ウォリンシュエビン