それで、クエリを実行する前にサーバーが常に稼働していることを確認するために、mysql サーバー (mysqli_ping) に ping を送信する必要があるかどうか疑問に思っていました。
9 に答える
次の 3 つの理由から、クエリの前に MySQL に ping を実行しないでください。
- クエリを実行しようとしたときにサーバーが稼働していることを確認する信頼できる方法ではありません。ping 応答とクエリの間にダウンする可能性があります。
- サーバーが稼働していても、クエリが失敗する場合があります。
- Web サイトへのトラフィックの量が増えると、データベースに多くの余分なオーバーヘッドが追加されます。この方法を使用して膨大な量のデータベース リソースが ping で無駄になっているエンタープライズ アプリでは珍しくありません。
データベース接続を処理する最善の方法は、エラー処理 (try/catch)、再試行、およびトランザクションです。
詳細については、 MySQLパフォーマンス ブログ を参照してください。
そのブログ投稿では、MySQL のそのインスタンスの負荷の 73% が、DB が稼働しているかどうかをチェックするアプリケーションによって引き起こされたことがわかります。
私はこれをしません。サーバーがなくなって何かをしようとすると、接続エラーが発生するという事実に依存しています。
pingを実行すると、少し時間が節約され、ユーザーへの応答が速くなるように見えるかもしれませんが、数秒待ってから接続エラーが発生するよりも、高速な接続エラーの方がはるかに優れているとは言えません。いずれにせよ、ユーザーはそれについて何もできません。
いいえ。
サーバーが実行されていることを確認するためだけに、ブラウザーでそこに移動する前に SO に ping を実行しますか?
それで、クエリを実行する前にサーバーが常に稼働していることを確認するために、mysql サーバー (mysqli_ping) に ping を送信する必要があるかどうか疑問に思っていました。
あまり。ライブでない場合は、クエリやデータベースへの接続時に表示されるエラー メッセージでわかります。次のコマンドで mysql エラーを取得できます。
mysql_error()
例:
mysql_connect(......) or die(mysql_error());
これは標準的な処理方法ではありません...例外があれば、そのときに処理します。
これは、ファイルを開こうとする前にファイルが存在することを確認することと、ファイルが見つからない例外が発生したときにキャッチすることの違いに似ています...非常に一般的でありそうなエラーである場合は、確認する価値があるかもしれませんただし、通常は実行が正常に行われようとし、例外が発生したときにキャッチして処理する必要があります。
一般的に言えば、いいえ。
ただし、実行時間の長いスクリプトがある場合、たとえば、接続と後続のクエリの間の時間間隔である cron ジョブとして呼び出されるバックエンド プロセスがmysqli_ping()
役立つ場合があります。
mysqli.reconnect
この場合、php.ini で true に設定すると便利です。
いいえ。
ping が成功したからといって、クエリが成功するとは限りません。ping を実行してからクエリを実行するまでの間にサーバーが使用できなくなった場合はどうなるでしょうか。
このため、とにかくクエリの周りで適切なエラーをキャッチする必要があります。その場合は、これを主要なエラー トラップとして使用することをお勧めします。
ping を追加すると、不要なラウンドトリップが追加されるだけで、最終的にコードが遅くなります。
これを実行する唯一の方法は、データベースが
1. アプリの機能にとって重要ではなく、
2. オフラインになる傾向がある場合です。
それ以外は、いいえ。
ping を使用する価値があるのは、独自のデータベース接続プール システムを実装している場合だけです。その場合でも、プールからの「接続」/チェックアウトごとに、すべてのクエリの前にpingを実行しません。