PHP é a maneira mais popular de criar um aplicativo Web do lado do servidor, com aproximadamente 80% de participação de mercado . (ASP.net está em um distante segundo lugar, e Java em um ainda mais distante terceiro lugar.)
O universo PHP inclui uma infinidade de frameworks PHP; os mais populares incluem Laravel, Phalcon e Symfony 2. O PHP também é a base para sistemas de gerenciamento de conteúdo (CMSs) populares, como WordPress e Drupal . (A versão mais recente do Drupal, o Drupal 8, inclui integração significativa com o Symfony 2 .
Agora, a equipe do PHP está lançando uma nova versão, o PHP 7 – mais de uma década após a introdução do PHP 5. Durante esse período, o uso da web e as demandas por sites aumentaram exponencialmente. O PHP contribuiu para esse rápido crescimento – mas as limitações do PHP também são destacadas pelo próprio crescimento que ele possibilitou.
O PHP é comumente visto como poderoso e flexível, mas sujeito a problemas de desempenho. Sites baseados em PHP podem facilmente “bater em uma parede” depois de apenas algumas duplicações nos números de tráfego. Assim que um site começa a atingir suas metas comerciais ou operacionais, ele começa a cair sempre que o volume de tráfego aumenta.
Para milhares e milhares de aplicativos baseados em PHP, algumas mudanças relativamente simples foram suficientes para melhorar o desempenho. Isso inclui cache com ferramentas como memcached
, ajuste de bancos de dados, proxy reverso e balanceamento de carga com NGINX Open Source e NGINX Plus . O NGINX melhorou muito a capacidade de resposta dos aplicativos, suportando aumentos de ordem de magnitude nos números de usuários e tráfego.
Esta postagem do blog é a primeira de uma série de duas partes sobre como maximizar o desempenho dos seus sites que usam PHP 7. Aqui, nos concentramos na atualização para PHP 7, implementando o NGINX Open Source ou NGINX Plus como seu software de servidor web, reescrevendo URLs (necessário para que as solicitações sejam tratadas corretamente), armazenando em cache arquivos estáticos e armazenando em cache arquivos dinâmicos (também chamado de cache de aplicativo ou microcache).
Na próxima postagem do blog, nos concentraremos nas etapas que você pode seguir com servidores adicionais: adicionar um servidor proxy reverso, migrar para vários servidores de aplicativos, balancear carga entre vários servidores, dar suporte à persistência de sessão durante o balanceamento de carga e encerrar protocolos de segurança, como SSL/TLS e o protocolo HTTP/2 relacionado.
Por que os aplicativos PHP não funcionam mais? Pelo mesmo motivo, qualquer software de servidor de aplicativos trava. Quando uma solicitação do usuário chega, o PHP – e o software do servidor web sobre o qual ele é executado – tem que fazer várias coisas:
Isso é muito para um servidor físico, máquina virtual ou instância de servidor em nuvem manipular para cada solicitação. O desempenho tende a cair quando a memória física na máquina do servidor – seja física ou virtual – se esgota. O servidor então começa a paginar as sessões atuais no disco conforme novas solicitações chegam. Aguardar o atendimento de solicitações de arquivo também introduz estados de espera que contribuem para a paginação. Depois de um ponto (muito limitado), as operações de paginação e as solicitações de dados sobrecarregam as operações de processamento, e o desempenho entra em uma espiral mortal que causa longas esperas ou o encerramento total da sessão para usuários frustrados.
Superar as barreiras de desempenho do PHP é certamente possível e requer várias etapas complementares. Cada etapa pode ser combinada com outras. Em linhas gerais, eles incluem:
Você não precisa implementar essas etapas em nenhuma ordem específica; por exemplo, mesmo se você mantiver o Apache como seu servidor web e não atualizar seu servidor de aplicativos para PHP 7, apenas implementar o NGINX como um proxy reverso "na frente" de seus servidores existentes melhora o desempenho e permite que você implemente vários servidores de aplicativos em paralelo.
Não importa como você faça as coisas, o principal fato a ter em mente é que você pode obter vários fatores de aumento de desempenho, até mesmo uma ordem de magnitude em capacidade, com pouca ou nenhuma alteração no código do seu aplicativo atual. Continue lendo para ver como as pessoas já alcançaram, ou estão em processo de alcançar, esses ganhos extraordinários de desempenho.
Observação : Há uma otimização multiservidor que ignoraremos um pouco nestas postagens do blog. Um servidor de banco de dados separado e uma rede de distribuição de conteúdo (CDN) podem aliviar a carga do seu servidor de aplicativos e melhorar muito o desempenho; esses tipos de alterações são separados e paralelos às melhorias de aplicativo e implementação descritas aqui.
O principal motivo para atualizar para o PHP 7, mais cedo ou mais tarde, é simples: velocidade do aplicativo (significativamente possibilitada pela economia de memória). Dizem que o PHP 7 é duas vezes mais rápido que as versões anteriores do PHP e usa consideravelmente menos memória. (Sua quilometragem sem dúvida variará em ambos os aspectos.)
O tempo de resposta é, simplesmente, crítico para aplicativos web. Um aplicativo da web mais rápido – que também usa menos memória, reduzindo a probabilidade de troca de páginas e problemas de desempenho resultantes – realiza três coisas:
Todos esses são excelentes motivos para fazer um upgrade; em conjunto, o argumento a favor da atualização parece quase irresistível. E “atualizar para a versão mais recente” é sempre a primeira recomendação para corrigir muitos problemas, mesmo quando não há um benefício de desempenho tão claro. Então por que nem todo mundo atualiza imediatamente?
Simples: as pessoas odeiam mexer em códigos antigos, e por um bom motivo. Se um aplicativo antigo estiver funcionando bem o suficiente e os desenvolvedores obtiverem melhores resultados criando novos aplicativos do que atualizando os antigos, o aplicativo antigo pode permanecer inalterado por muito tempo. (Veja a segunda postagem do blog desta série para obter informações sobre como usar o NGINX para melhorar o desempenho do seu aplicativo sem nenhuma alteração no seu servidor web e aplicativo atuais.)
Mas a coisa mais eficiente a fazer, se possível, é começar sua busca por maior desempenho atualizando para o PHP 7. Mas não comece até ter tempo suficiente para terminar, principalmente sem economizar nos testes.
Vamos dar uma olhada no que é preciso para atualizar para o PHP 7:
switch
versus if-then-else
.) Este blog no Engine Yard tem bons exemplos da maioria desses problemas.
Se você decidir prosseguir e atualizar para o PHP 7, considere fazer uma revisão completa de desempenho e revisão do seu código, ou pelo menos de seus recursos críticos, aproveitando os novos recursos do PHP 7. Não há melhor maneira para você e sua equipe se qualificarem, e as mudanças que você fizer, revisar e testar hoje provavelmente servirão a você por muitos anos. Você também aproveitará ao máximo as outras sugestões de desempenho nesta postagem do blog, porque o código otimizado se beneficia muito da execução em um ambiente otimizado.
Portanto, apesar do fato de que os sites geralmente implementam o NGINX para obter melhor desempenho sem alterar o código do aplicativo, recomendamos que você tome a iniciativa e siga em frente. Há muita ajuda disponível para fazer essa mudança, ou você pode simplesmente arregaçar as mangas e fazer você mesmo . Há um guia de migração para o PHP 7 no site oficial do PHP e um livro de instruções sobre atualização do PHP 7 da O'Reilly.
NGINX é o software que executa mais de 140 milhões de sites, incluindo metade dos 10.000 sites mais movimentados . (Essas medições detectam o servidor web em sites de servidor único e o servidor proxy reverso em sites de vários servidores.) Como um servidor web, ambos oferecem um aumento imediato de desempenho – em alguns casos, onde um servidor executando outro software foi sobrecarregado e sofreu uma sobrecarga de até 10 vezes. Como um servidor proxy reverso, ambos permitem o uso de vários servidores dedicados para dimensionar uma implantação conforme necessário.
Tanto o PHP quanto o Apache atribuem recursos a cada solicitação aberta; se um ou ambos tiverem que carregar várias bibliotecas, o tempo de inicialização por solicitação e o consumo de memória podem ser consideráveis. Migrar para o NGINX como seu software de servidor web elimina esse problema no nível do servidor. Usar a funcionalidade do NGINX para descarregar trabalho para o servidor web (como servir arquivos estáticos) ou para um servidor proxy reverso (todos os tipos de cache, terminação de protocolo, balanceamento de carga, etc.) minimiza o que o PHP precisa fazer, simplificando e acelerando o processamento do aplicativo.
Se você tiver módulos Apache personalizados ou proprietários para seu site, talvez não seja possível substituir o Apache pelo NGINX até substituir os módulos. Verifique com o NGINX se há soluções alternativas fáceis; caso contrário, dimensione o tempo e o esforço necessários para fazer a alteração.
Depois de decidir usar o NGINX, você pode escolher entre o NGINX Open Source e o NGINX Plus. Alguns dos recursos mais proeminentes do NGINX Plus em relação ao NGINX Open Source são:
Como um servidor proxy reverso, o NGINX Plus tem vantagens adicionais:
Tanto o NGINX Open Source quanto o NGINX Plus oferecem suporte ao cache de conteúdo e ao microcache (também chamado de cache de aplicativo ). O armazenamento em cache é útil no contexto do servidor web, pois alivia a carga do servidor de aplicativos, mas ambas as funções ainda compartilham uma única máquina ou instância de máquina virtual. Em um servidor proxy reverso, o armazenamento em cache pode aliviar uma quantidade significativa de trabalho do dispositivo do servidor de aplicativos, oferecendo maiores vantagens de desempenho.
Você pode baixar o software NGINX Open Source diretamente do nginx.org , onde também encontrará suporte da comunidade . Para iniciar uma assinatura única do NGINX Plus, registre-se para um teste gratuito de 30 dias ou compre on-line . Para pacotes multiinstância, entre em contato com o departamento de vendas da NGINX .
Ao migrar do Apache para o NGINX como seu software de servidor web, há algumas mudanças que você precisa fazer – detalhadas em um excelente artigo no sitepoint.com :
mod_rewrite
, por exemplo). Substitua-as pelas especificações de configuração relevantes nos arquivos de configuração do NGINX. Para alguns exemplos, veja nosso blog .Fazer essas alterações familiariza você com o NGINX e o prepara para otimizar sites mais complexos, conforme descrevemos na Parte 2 desta postagem do blog. No entanto, se fazer essas alterações de configuração representar uma quantidade inaceitável de trabalho ou grau de risco para as operações do seu site, não tenha medo: você pode implementar as arquiteturas multisservidor descritas na Parte 2 sem atualizar o software do servidor web principal do Apache e, portanto, sem alterar os arquivos de configuração do servidor web.
Arquivos estáticos são simplesmente arquivos que não mudam com frequência, pelo menos em termos de servidor web. Arquivos estáticos geralmente incluem arquivos gráficos, como JPEGs e PNGs, e arquivos de código, como CSS e JavaScript. Se você colocar esses arquivos no seu servidor de aplicativos ou em um servidor de banco de dados separado, as solicitações para eles terão que ser processadas pelo código do aplicativo, com toda a sobrecarga necessária para fazer e atender uma solicitação. Isso “distrai” o servidor de aplicativos de trabalhos mais importantes e pode levá-lo mais perto do ponto em que a memória física fica sobrecarregada e novas solicitações fazem com que as solicitações atuais sejam paginadas para o disco.
O cache de arquivo estático é uma função central do NGINX. Você pode implementá-lo em um servidor web ou em um servidor proxy reverso:
Há três etapas gerais para implementar o cache de arquivos estáticos no NGINX:
Em um servidor web NGINX, sem nenhum servidor proxy reverso envolvido, você não armazena em cache no sentido usual. Você simplesmente redireciona as consultas de arquivos estáticos para o servidor web, usando o cabeçalho X-Accel-Redirect
. O servidor de aplicativos nunca vê a solicitação e pode dedicar todos os seus recursos às solicitações do aplicativo. Com um servidor proxy reverso, você usa cache de arquivo estático – e o servidor físico ou a instância do servidor virtual que executa o aplicativo não tem nenhuma participação na resposta às solicitações de arquivo estático.
Como exemplo de otimização da velocidade de resposta, o seguinte snippet de configuração permite que o NGINX use a chamada de sistema sendfile
do sistema operacional, o que economiza uma etapa na transmissão do arquivo ao não copiá-lo para um buffer intermediário:
localização /mp3 { sendfile on;
sendfile_max_chunk 1m;
# ...
}
Para obter detalhes sobre como configurar o NGINX para cache de arquivos estáticos, consulte o Guia de administração do NGINX Plus .
O microcaching, confusamente, tem muitos nomes, que também incluem cache de aplicativo e cache simples. Aqui na NGINX, usamos o termo microcaching para enfatizar o breve período em que esses arquivos são válidos.
Digamos que você tenha uma página de postagem de blog que fornece um mecanismo para comentários de usuários. Você quer incluir os comentários mais recentes e melhores sempre que um novo visitante chega à página – ou sempre que usuários existentes atualizam a página para ver seus próprios comentários, ou os de outra pessoa. Nesse caso, parece uma boa ideia gerar a página novamente toda vez que alguém a visita.
No entanto, “toda vez” pode se tornar um fardo. Se uma página recebe uma visita por segundo, faz sentido gerá-la novamente para cada visita. Mas se a página estiver recebendo dez, cem ou mil visitas por segundo, junto com todas as outras páginas do site, o servidor do aplicativo pode ficar sobrecarregado. Alcançar a meta de fornecer conteúdo novo às pessoas significa que ninguém obtém conteúdo rapidamente.
Microcaching significa gerar uma página uma vez marcando a versão em cache como válida por um breve período de tempo – digamos, um ou alguns segundos. Quando a versão em cache expira, a próxima solicitação solicita a geração de uma nova página e as solicitações logo depois obtêm sua versão em cache. Esse é o mesmo comportamento de um arquivo estático, mas em períodos de tempo muito mais curtos.
Esta imagem indica onde procurar no seu site por conteúdo que você pode armazenar em microcache. É de uma postagem de blog sobre microcaching do nosso próprio Owen Garrett.
O microcaching é incrível porque remove o trabalho do servidor de aplicativos exatamente quando ele é mais necessário, e com muito pouco ou nenhum prejuízo para o usuário. É tão incrível que está embutido em alguns sistemas. O Drupal considera seus recursos robustos e integrados de microcaching tão essenciais que, no mundo Drupal, o microcaching é simplesmente chamado de “caching”.
Mas a solução Drupal é um pouco deficiente, assim como qualquer solução similar. O servidor de aplicativos faz menos trabalho, mas ainda é o Drupal (ou, mais genericamente, o PHP) que tem que gerenciar a configuração, a implementação e o serviço de arquivos. Ao usar o NGINX para microcaching, o servidor de aplicativos fica totalmente livre de qualquer tarefa, exceto de gerar uma nova página na frequência especificada pelo microcache. Ele nem mesmo vê as outras solicitações, muito menos precisa armazenar ou recuperar nada para acessos de cache.
Usando o NGINX Plus ou outras ferramentas, você pode monitorar seu site e ver quais páginas serão beneficiadas pelo microcaching. O seguinte snippet de configuração implementa um período de cache de 1 segundo para respostas com um 200
Código de status OK
.
proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inativo=600s max_size=100m;servidor {
proxy_cache cache;
proxy_cache_valid 200 1s;
# ...
}
Esta primeira parte do nosso post do blog PHP é focada em soluções de servidor único, além de cache, que é eficaz em implementações de servidor único – mas ainda mais quando um servidor proxy reverso está na mistura. A Parte 2 descreve os benefícios de um servidor proxy reverso, implementação multiservidor em torno do seu aplicativo PHP.
Para experimentar o NGINX Plus, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso.
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."