php+mysql の開発プロセス中、データベースに接続するためのホスト名を入力する場合、ローカル マシンは通常、localhost または 127.0.0.1 を使用できますが、実際のアプリケーション プロセスでは Linux システムに異常は見つかりませんでした。 Windows サーバー システムでは、localhost を記述すると、Web ページの応答が比較的遅くなり、ページが完了するまでに 1 秒以上かかります。プログラムの実行時間を段階的に判断したところ、問題があることがわかりました。 mysql に接続するとき、接続を確立するのに 1 秒近くかかります。問題がある場合は、この状況が存在することを確認してください。その抜粋は次のとおりです。
HTTP://blog.Sina.com.abilities/是/blog_6cost 5ah 76 毛 0100 一枚絵.HTML
最近、プログラムの応答時間が少し遅いことに気づき、それを徐々に排除し、各プログラムの実行時間を計算しましたが、最終的にはデータベースへのリンクに時間がかかることがわかりました。データベースがあったので、それを置きました。
翌日、データベースへのリモート リンクをテストしたところ、IP を使用してデータベースにアクセスする場合の実行時間は非常に短く、localhost を使用してデータベースにローカルに接続する場合よりもはるかに短いことがわかりました。したがって、次のテストがあります。
set_time_limit(0) ; $localtime = 0 ; for($i=1;$i<=50;$i++){ $btime = get_microtime() ; $conn = new mysqli("localhost","root","admin","") ; $conn-close() ; $etime = get_microtime() ; $localtime += $etime-$btime ; } $iptime =0 ; for($i=1;$i<=50;$i++){ $btime = get_microtime() ; $conn = new mysqli("127.0.0.1","root","admin","") ; $conn-close() ; $etime = get_microtime() ; $iptime += $etime-$btime ; } echo "localhost时间损耗为：".($localtime)/$i."<br /" ; echo "127.0.0.1时间损耗为：".($iptime/$i)."<br /" ; function get_microtime(){ list($micro,$time) = explode(" ",microtime()); return $time+$micro ; }
出力結果は次のとおりです。 localhost の時間損失は 0.98833055122226 です。
127.0.0.1 の時間損失は次のとおりです: 0.0039590807522044
2 つの接続方法の所要時間は大きく異なります。この質問に答えられる専門家がいれば幸いです。
おそらく DNS 解決が原因か、ローカルホストの解決に時間がかかるのではないかと推測しました。 ウィンドウ システムを使用していることを説明してください。
理由の説明:
これは確かにオペレーティング システムの解析の問題です。詳細については、http://www.cnblogs.com/hayywcy/p/5341550.html を参照してください。
今日、localhost にアクセスすると、「404 が見つかりません」というメッセージが表示されましたが、127.0.0.1 にはアクセスできました。最終的に、Windows が localhost を 127.0.0.1 ではなく ipv6 アドレス::1 に解決したため、その理由が判明しました。ホストを確認したところ、ipv6 がブロックされていることがわかりました。127.0.0.1 localhost もありますが、正常に解析できません。 Baidu は長い間検索しましたが無駄でした。最終的に、科学的なインターネット手法を使用して Google で解決策を見つけました。元の投稿が失われないように、ここに再投稿しました (元の投稿アドレス: http://superuser.com/questions/)。 436574/ipv4-vs-ipv6-windows-7 の優先順位-7/436944#436944)。
記事の内容:
解決策 1: IPV6 よりも IPV4 アドレスを優先するプレフィックス ポリシーを追加する プレフィックス ポリシー テーブルはルーティング テーブルに似ており、接続時にどの IP アドレスが優先されるかを決定します。プレフィックス ポリシーの優先順位が高いほど、「優先順位」が高くなります。ルーティング テーブルの「コスト」値とは正反対の値です。
デフォルトの Windows プレフィックス ポリシー テーブル:
C:\netsh Interface ipv6 show prefixpolicies アクティブ状態をクエリしています...
優先順位 ラベル プレフィックス
---------- ----- ------------------------ ---
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
20 3 ::/96
10 4 ::ffff:0:0/96
5 5 2001::/32 IPv6 アドレス (::/0) が IPv4 アドレス (::/96、::ffff:0:0/96) よりも優先されることに注意してください。 。
Hurricane Electric IPv6 トンネルがどの IPv4 アドレスよりも不利になるポリシーを作成できます。
netsh Interface ipv6 add prefixpolicy 2001:470::/32 3 6 2001:470::/32 は Hurricane Electric のプレフィックス、3 は優先順位 (非常に低い)、6 はラベルです。
より汎用的なプレフィックスを使用することもできましたが、ISP から直接 IPv6 接続を取得した場合に、それが IPv4 よりも優先されることを確認したかったのです。
このソリューションを適用する場合は、Hurricane Electric のプレフィックスの代わりに適切な IPv6 プレフィックスを使用する必要があります。
解決策 #2: レジストリを調整して、Windows が常に IPV6 よりも IPV4 を優先するようにする
このソリューションはより汎用的ですが、侵襲性が高く、標準への準拠性も低くなりますが、最終的には Windows がプレフィックス ポリシー テーブルを変更します。
RegEdit を開き、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters に移動します。 DisabledComponents DWORD レジストリ値を作成し、その値を 20 (16 進数) に設定します。
このレジストリ キーの詳細については、特に DisabledComponents がシステムに存在する場合は、Microsoft KB 929852 を参照してください。
翻訳によると、Windows には優先解析リストがあり、ipv6 が ipv4 よりも高い場合、今日遭遇した状況が発生します (ただし、その理由はまだ見つかっていません)。 1 つ目の方法は、ipv6 よりも高い ipv4 の優先度を持つレコードを優先度解析テーブルに追加することです。理解できない単語が多く、パラメーターを間違えるのが怖いため、あえて使用しません。 2番目のレジストリを変更する方法で解決しました。方法は次のとおりです（英語がわからない場合は確認する必要はありません）。
レジストリを開き、キー HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters を見つけて、DisabledComponents という名前の DWORD 型の項目を追加します (既に存在する場合は、それを追加して値を直接変更する必要はありません) ）。次に、値を 20 に変更し、値のタイプを 16 進数に変更します。以上です、レジストリを保存してコンピュータを再起動します。 localhost にもう一度 ping を実行してみてください。