During the development process of php+mysql, when filling in the host name for connecting to the database, the local machine can generally use localhost or 127.0.0.1. In the actual application process, no abnormalities have been found in the Linux system, but in the Windows server system, there are When writing localhost, the web page response will be relatively slow. Generally, it takes more than 1 second to complete a page. I judged the program running time step by step and found that it was a problem when connecting to mysql. It takes nearly 1 second to establish a connection. It must be If there is a problem, search it and find that this situation does exist. Many programmer blogs have responded. The excerpt is as follows:

HTTP://blog.Sina.com.abilities/是/blog_6cost 5ah 76 hair 0100 one painting.HTML

Recently I found that the response time of the program was a bit slow, so I gradually eliminated it and calculated the execution time of each program. Finally, I found that the time wasted on linking to the database. There was no good way to link the database, so I put it down.

The next day, I tested the remote link to the database and found that the execution time of using IP to access the database was very short and much shorter than when I used localhost to connect to the database locally. So we have the following test:

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 ;
}


The output result is: localhost time loss is: 0.98833055122226

The time loss of 127.0.0.1 is: 0.0039590807522044

 

The time consumption of the two connection methods is very different. It would be great if there are experts who can help answer this question.

I guessed that it might be due to DNS resolution, or that localhost resolution takes time. Please explain that I am using a window system.

Reason explanation:

It is indeed a problem of operating system parsing. For details, please refer to http://www.cnblogs.com/hayywcy/p/5341550.html

I encountered a strange problem today. When accessing localhost, it prompted not found 404, but 127.0.0.1 was accessible. Finally, the reason was found because Windows resolved localhost to the ipv6 address::1 instead of 127.0.0.1. I checked the hosts and found that ipv6 has been blocked. There is also 127.0.0.1 localhost, but it cannot be parsed normally. Baidu searched for a long time to no avail, and finally found a solution on Google using scientific Internet methods. To prevent the original post from being lost, I reposted it here (original post address: http://superuser.com/questions/436574/ipv4-vs-ipv6- priority-in-windows-7/436944#436944).

Article content:

SOLUTION #1: ADD A PREFIX POLICY TO PREFER IPV4 ADDRESSES OVER IPV6 Prefix policy table is similar a routing table, it determines which IP addresses are preferred when making a connection. Note that higher precedence in prefix policies is represented by a lager "precedence" value, exactly opposite to routing table "cost" value.

Default Windows prefix policy table:

C:\netsh interface ipv6 show prefixpolicies Querying active state...

 Precedence  Label  Prefix

 ----------  -----  -------------------------- ---

 50      0  ::1/128

 40      1  ::/0

 30      2  2002::/16

 20      3  ::/96

 10      4  ::ffff:0:0/96

  5      5  2001::/32 Note that IPv6 addresses (::/0) are preferred over IPv4 addresses (::/96, ::ffff:0:0/96) .

 

We can create a policy that will make Hurricane Electric IPv6 tunnel less favorable than any IPv4 address:

netsh interface ipv6 add prefixpolicy 2001:470::/32 3 6 2001:470::/32 is Hurricane Electric's prefix, 3 is a Precedence (very low) and 6 is a Label.

I could have used a more generic prefix, but I wanted to make sure than if and when I get a direct IPv6 connectivity from an ISP, it will take precedence over IPv4.

If you adapt this solution, you need to substitute an appropriate IPv6 prefix instead of my Hurricane Electric one.

SOLUTION #2: TWEAK REGISTRY TO MAKE WINDOWS ALWAYS PREFER IPV4 OVER IPV6

This solution is more generic, but more invasive and less standards-compliant. In the end, Windows will still modify the prefix policy table for you.

Open RegEdit, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters Create DisabledComponents DWORD registry value, set its value to 20 (Hexadecimal).

SeeMicrosoft KB 929852 for more info about this registry key, especially if DisabledComponentsalready exists on your system. Reboot.

According to the translation, Windows has a priority parsing list. When ipv6 has a higher priority than ipv4, the situation I encountered today will occur (although the reason for this is still not found). The first way is to add a record with a priority of ipv4 higher than ipv6 to the priority parsing table. Because many words cannot be understood, and I am afraid of getting the parameters wrong, I dare not use it. I solved it with the second method, which is to modify the registry. The method is as follows (if you don’t understand English, you don’t need to check it):

Open the registry, find the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters, and add an item of type DWORD with the name DisabledComponents (if you already have one, you don’t need to add it and change the value directly). Then modify the value to 20 and the value type to hexadecimal. That's it, save the registry and restart the computer. Try pinging localhost again and try.


Leave a Reply