Durante o processo de desenvolvimento do php+mysql, ao preencher o nome do host para conexão ao banco de dados, a máquina local geralmente pode usar localhost ou 127.0.0.1. No processo de aplicação real, nenhuma anormalidade foi encontrada no sistema Linux, mas. no sistema de servidor Windows, existem Ao escrever localhost, a resposta da página da web será relativamente lenta. Geralmente, leva mais de 1 segundo para concluir uma página. Julguei o tempo de execução do programa passo a passo e descobri que era um problema. ao conectar-se ao mysql. Demora quase 1 segundo para estabelecer uma conexão. Se houver um problema, pesquise e descubra que esta situação existe.
HTTP://blog.Sina.com.abilities/是/blog_6cost 5ah 76 cabelo 0100 uma pintura.HTML
Recentemente descobri que o tempo de resposta do programa era um pouco lento, então eliminei-o gradativamente e calculei o tempo de execução de cada programa. Por fim, descobri que o tempo perdido na vinculação ao banco de dados Não havia uma boa maneira de vincular. o banco de dados, então eu o coloquei de lado.
No dia seguinte, testei o link remoto com o banco de dados e descobri que o tempo de execução do uso de IP para acessar o banco de dados era muito curto e muito menor do que quando usei localhost para conectar-me localmente ao banco de dados. Então temos o seguinte teste:
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 ; }
O resultado da saída é: a perda de tempo do host local é: 0,98833055122226
A perda de tempo de 127.0.0.1 é: 0,0039590807522044
O consumo de tempo dos dois métodos de conexão é muito diferente. Seria ótimo se houvesse especialistas que pudessem ajudar a responder a esta pergunta.
Imaginei que poderia ser devido à resolução do DNS ou que a resolução do host local leva tempo. Por favor, explique que estou usando um sistema de janelas.
Explicação do motivo:
Na verdade, é um problema de análise do sistema operacional. Para obter detalhes, consulte http://www.cnblogs.com/hayywcy/p/5341550.html.
Encontrei um problema estranho hoje ao acessar o localhost, ele não encontrou 404, mas 127.0.0.1 estava acessível. Finalmente, o motivo foi encontrado porque o Windows resolveu o localhost para o endereço ipv6::1 em vez de 127.0.0.1. Verifiquei os hosts e descobri que o ipv6 foi bloqueado. Também existe 127.0.0.1 localhost, mas não pode ser analisado normalmente. O Baidu procurou por muito tempo sem sucesso e finalmente encontrou uma solução no Google usando métodos científicos da Internet. Para evitar que a postagem original fosse perdida, eu a repostei aqui (endereço da postagem original: http://superuser.com/questions/). 436574/ipv4-vs-ipv6-prioridade-no-windows-7/436944#436944).
Conteúdo do artigo:
SOLUÇÃO #1: ADICIONE UMA POLÍTICA DE PREFIXO PARA PREFERIR ENDEREÇOS IPV4 SOBRE IPV6 A tabela de políticas de prefixo é semelhante a uma tabela de roteamento, ela determina quais endereços IP são preferidos ao fazer uma conexão. Observe que a precedência mais alta nas políticas de prefixo é representada por uma "precedência" lager. valor, exatamente oposto ao valor de "custo" da tabela de roteamento.
Tabela de política de prefixo padrão do Windows:
C:\netsh interface ipv6 show prefixpolicies Consultando estado ativo...
Precedência Rótulo Prefixo
---------- ----- -------------------------- ---
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
20 3 ::/96
10 4 ::ffff:0:0/96
5 5 2001::/32 Observe que os endereços IPv6 (::/0) são preferidos aos endereços IPv4 (::/96, ::ffff:0:0/96) .
Podemos criar uma política que tornará o túnel Hurricane Electric IPv6 menos favorável do que qualquer endereço IPv4:
netsh interface ipv6 add prefixpolicy 2001:470::/32 3 6 2001:470::/32 é o prefixo do Hurricane Electric, 3 é uma precedência (muito baixa) e 6 é um rótulo.
Eu poderia ter usado um prefixo mais genérico, mas queria ter certeza de que, se e quando obtiver conectividade IPv6 direta de um ISP, ela terá precedência sobre o IPv4.
Se você adaptar esta solução, precisará substituir um prefixo IPv6 apropriado em vez do meu prefixo Hurricane Electric.
SOLUÇÃO #2: AJUSTE O REGISTRO PARA FAZER O WINDOWS SEMPRE PREFERIR IPV4 A IPV6
Esta solução é mais genérica, mas mais invasiva e menos compatível com os padrões. No final, o Windows ainda modificará a tabela de políticas de prefixo para você.
Abra o RegEdit, navegue até HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters Crie o valor de registro DWORD DisabledComponents, defina seu valor como 20 (Hexadecimal).
Consulte Microsoft KB 929852 para obter mais informações sobre essa chave de registro, especialmente se DisabledComponents já existir em seu sistema.
De acordo com a tradução, o Windows tem uma lista de análise de prioridade. Quando o ipv6 tem uma prioridade mais alta que o ipv4, a situação que encontrei hoje ocorrerá (embora o motivo para isso ainda não tenha sido encontrado). A primeira maneira é adicionar um registro com prioridade ipv4 superior a ipv6 à tabela de análise de prioridade. Como muitas palavras não podem ser entendidas e tenho medo de errar nos parâmetros, não me atrevo a usá-lo. Resolvi com o segundo método, que é modificar o registro. O método é o seguinte (se você não entende inglês, não precisa verificar):
Abra o registro, encontre a chave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters e adicione um item do tipo DWORD com o nome DisabledComponents (se já houver um, você não precisa adicioná-lo e alterar o valor diretamente ). Em seguida, modifique o valor para 20 e o tipo de valor para hexadecimal. É isso, salve o registro e reinicie o computador. Tente executar ping no localhost novamente e tente.