Temos dois servidores GoDaddy que armazenam um aplicativo do Facebook. Um é para testes e o outro é para produção. Ambos têm o mesmo código, mas o servidor de teste responde muito mais rápido.
Ambas as configurações dos servidores são:
E os dois têm o mesmo hardware.
Estamos tentando rastrear o problema, primeiro testamos nosso código monitorando o uso de nossas porcentagens de uso do php & mysql por top . Nós administramos não excedendo 10%. Estou lembrando que os dois servidores têm o código SAME .
Em segundo lugar, alteramos o arquivo de configuração do MySQL na produção para ser exatamente como o servidor de teste, mas isso também não ajudou.
Conforme testamos nosso aplicativo com firebug , descobrimos um grande atraso em alguns arquivos .php . Algumas solicitações de arquivos .php demoram 2 segundos no servidor de teste e 13 segundos no servidor de produção. Como esse atraso persistiu APENAS no servidor de produção, comparamos o resultado de ambos os resultados phpInfo() .
As diferenças podem ser vistas aqui:
Diferenças dos resultados do phpinfo ()
Todas as diferenças estão listadas neste formulário:
******Testing //A result from our testing server (Empty means not exist)
******Production //A result from our production server (the SLOW one)
HTTP_CACHE_CONTROL
Você vê alguma diferença que possa causar problemas de desempenho?
Obrigado.
Os dois servidores estão atualizados? Há obviamente discrepâncias em pelo menos a versão do Memcached do PHP entre as duas caixas.
Se isso não acontecer, pode haver um problema de hardware? Um arranjo RAID quebrado ou similar pode causar lentidão em certas situações.
Uma forma possível de depurar a lentidão pode ser executar um script PHP de amostra (um que mostre uma discrepância de velocidade entre os dois servidores) sob strace e, em seguida, descobrir em que ponto a desaceleração ocorre.
Isso soa muito como bloqueio. Você está usando tabelas MyISAM? Uma consulta de gravação a uma tabela MyISAM bloqueia a tabela inteira, o que fará com que qualquer solicitação de leitura simultânea tenha que esperar até que a gravação seja concluída. Como a única diferença entre os servidores é o número de solicitações simultâneas, este é meu primeiro palpite. O InnoDB possui bloqueio em nível de linha para gravações, o que o torna uma opção melhor para esse tipo de carga de trabalho de leitura / gravação.
O cache de consulta do MySQL também pode ser um ponto de bloqueio, já que todas as entradas de uma determinada tabela precisam ser liberadas toda vez que qualquer gravação for feita nessa tabela. Caches de consulta maiores nem sempre são melhores e podem causar grandes lentidões.
Você tem seu log lento do MySQL ativado? Você também pode querer adicionar log_queries_not_using_indexes . Contenção de disco seria meu segundo palpite. A saída de vmstat 5 5 deve ajudar a determinar isso. (Como sempre com vmstat , ignore a primeira linha.) Se esse for o seu problema, você poderá resolvê-lo da seguinte maneira:
Provavelmente também vale a pena correr mysqltuner.pl no seu servidor MySQL. Para obtê-lo, basta digitar wget mysqltuner.pl .
Você já entrou em contato com a GoDaddy sobre esse problema?
Se você está certo de que a pilha da Web é idêntica (configuração MySQL / configuração Apache / PHP / código-fonte), então há claramente um problema de configuração em um nível além do seu alcance (rede / disco / camada de virtualização, assumindo que eles ' está empregando a virtualização no GoDaddy; não está familiarizado com suas ofertas de servidor virtual privado).
Se é apenas hospedagem compartilhada (e talvez até mesmo VPSs, quem sabe; novamente entre em contato com o Go Daddy) você nunca sabe qual caixa vai receber: Eu tenho uma conta de revenda com outro grande provedor de hospedagem e posso dizer IP, que eu vou pegar um servidor "cachorro", um com uma tonelada de contas nele (fiz uma contagem de subdiretórios em / home para provar isso). Na verdade, em geral, a hospedagem compartilhada é bem irregular: eu realmente só a uso para sites de folhetos de 3 pagers.
Tags performance php linux apache-2.2