Linux servidor web PHP terrivelmente lento quando acessado a partir de qualquer navegador do Windows

1

Eu tenho um servidor Linux (Ubuntu 10.04) executando o apache2 e o PHP. Tudo funciona bem ao acessar uma página de qualquer navegador de outra máquina Linux ou Mac. Mas quando tento acessar uma página de qualquer combinação de máquina e navegador do Windows, fico com um atraso de 30 segundos antes que a página volte. Acessar um arquivo HTML antigo simples a partir do navegador do Windows executa lickity split. Então parece ser apenas PHP. O MySQL está instalado, mas uma página de teste simples que não usa o MySQL ainda é lenta.

Eu não acho que é DNS, porque se eu codificar o endereço IP na URL nada muda. Não parece haver nada nos arquivos de log que eu possa dizer.

O que poderia estar causando esse comportamento em clientes Windows?

    
por Ed Harcourt 20.03.2012 / 01:57

1 resposta

1

Atualização: algumas dicas de depuração da "terceira base";

Uma maneira bastante brutal de obter alguma depuração é para rastrear o processo de execução do apache, e isso é realmente mais fácil porque os processos serão suspensos por um tempo.

Este comando abaixo só funcionará como indicado se o seu apache estiver no modo prefork, mas eu diria que ele funcionaria vagamente no modo de trabalho. (mas você teria que gastar algum tempo obtendo um ps e grep para encontrar os ids do thread ...) de qualquer maneira eu acho que o php requer prefork ...

Primeiro, verifique se o servidor está no modo prefork ...

root@server-72839:/home/ubuntu# apachectl -V | grep MPM
Server MPM:     Prefork             <----------- prefork mode works with php
 -D APACHE_MPM_DIR="server/mpm/prefork"

instale strace

root@server-72839:/home/ubuntu# apt-get install strace

faça alguma solicitação ao servidor e, em seguida, execute o seguinte comando para rastrear os syscalls feitos pelo processo interrompido;

 root@server-72839:~# netstat -antp | grep "ESTABLISHED" | grep 80 | while read _ _ _ _ client _ proc; do strace -f -p ${proc#/*} &  done



root@server-72839:~# Process 21570 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
chdir("/")                              = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb16b0000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb16ae000

deixe a solicitação de página ser executada em uma caixa de texto que é lenta e cole toda a saída novamente em um pastebin e coloque o link em um comentário.

Se você não tiver nenhuma alegria com isso, ative a depuração do php e o httpd Loglevel para depurar e colar tudo isso em um pastebin e forneça o link ....

Edit: (ok, talvez não definitivamente) possivelmente um problema de DNS reverso no servidor apache. tente o seguinte ....

verifique se você definiu HostnameLookups Off no seu servidor apache.

link

Verifique também se o seu resolv.conf está especificando os servidores de nomes de trabalho;

[root@workstation001 /root]# cat /etc/resolv.conf 
....
nameserver 192.168.1.254       <---- this must work. test it with dig

teste o servidor de nomes com dig;

 [root@workstation001 /root]# dig @192.168.1.254 www.google.co.uk +short
 www-cctld.l.google.com.
 173.194.67.94

faça o servidor de nomes funcionar, alterando-o para 8.8.8.8 (servidor de DNS público do google)

/etc/resolv.conf

 nameserver 8.8.8.8
 nameserver 8.8.8.4

Comece verificando os arquivos de logs do php.log e do apache para as conexões que são lentas, o problema provavelmente está presente nos logs.

No entanto, se tiver certeza de que este não é um problema de DNS (que você pode verificar usando a ferramenta de linha de comando nslookup) e não há nada óbvio, usei as ferramentas de desenvolvedor do google chrome para ver a linha do tempo do carregamento da página.

Isto irá dizer-lhe qual item na página está demorando tanto, e se o atraso é durante a conexão, ou durante o carregamento de recursos, etc.

Você pode passar para ferramentas como wget, curl no cygwin ou telnet simples para investigar mais a partir do lado do cliente.

    
por 20.03.2012 / 03:00