Este artigo será útil para pessoas que já possuem seu próprio site ou que planejam abri-lo. Artigo particularmente interessante serão webmasters ambiciosos que acham que a melhor hora de seu projeto está chegando e querem se preparar para o fluxo de visitantes da página.
Mesmo aqueles que ainda sonham com milhares de usuários em seu site, provavelmente se perguntaram: "Quantos usuários meu site permanecerá se eles fizerem login ao mesmo tempo?" Lembro-me imediatamente da famosa expressão “Habraeffect” - o fenômeno de falha no site, que acabou por não estar pronto para vários cliques após o aparecimento do link na Internet.
Suponha que o site já exista (ou será em breve): onde ele pode ser localizado? Deve ser um servidor de hospedagem ou vps clássico? Se vps, qual e como é melhor configurá-lo? Ou talvez não haja diferença alguma e seja mais fácil escolher o que é mais barato? Neste artigo, consideraremos várias opções e, na prática, garantiremos qual é a melhor para o nosso site.
Vamos experimentar: definir diferentes modos de operação do servidor e medir o desempenho. Simularemos a carga no site usando o serviço Loaddy.com. Lá, você pode definir o número de usuários, o tipo crescente de carga e o gráfico mostrará como o servidor responde a eles. Acredita-se que um usuário gere aproximadamente uma solicitação ao site em 10 segundos. Como site de teste, faça uma loja virtual de demonstração no cms moguta. Ele será preenchido com “mercadorias” de teste que são exibidas na página principal de acordo com vários critérios (ou seja, quando a página está sendo formada, o trabalho está em andamento com o banco de dados, etc.). De uma forma ou de outra, isso permitirá comparar os modos entre si.
Como site de teste, criaremos um servidor VPS no Ubuntu. Sua configuração será [1 núcleo, 1 GB de RAM]. Assumimos que são precisamente esses servidores de nível de entrada que são criados na maioria dos casos para novos projetos. A versão de teste da loja online estará disponível no endereço IP
http://130.193.44.219/A hospedagem clássica também é útil, para a qual também preencheremos a mesma loja online para realizar testes. Você pode seguir nosso próprio caminho e realizar os mesmos testes em seu projeto!
Como na maioria dos casos, um painel de controle é oferecido juntamente com os vps, faremos as principais alterações nas configurações nele. No servidor vps, temos 3 modos de operação:
- Apache
- Apache no modo CGI;
- Nginx + php-fpm (sem Apache).
Mas primeiro, vamos testar a hospedagem:
Hospedagem clássica de baixo custo
O resultado está disponível
aqui .
Os erros aparecem quando o número de visitantes excede 50 pessoas. A hospedagem deixa de fornecer conteúdo; no entanto, se você for ao painel de controle da hospedagem, podemos ver algo como o seguinte:
Seu site está sujeito a restrições nas últimas 24 horas. Os recursos do processador foram limitados para o seu site. Você atingiu os limites dos processos de entrada (o número de scripts PHP e CGI em execução simultaneamente, tarefas agendadas e sessões do console) 126 vezes.
Bem, é claro, hospedagem é hospedagem, ainda mais barata. Você pode, é claro, encontrar uma tarifa que ofereça mais opções, mas é necessário considerar tudo isso, descobrir de alguma forma os dados exatos das restrições e cada provedor de hospedagem.
VPS: Apache
O próximo na fila é o nosso teste da Força Aérea com o modo Apache, que por sinal é oferecido por padrão ao instalar o painel de controle do ISP.
O resultado está disponível
aqui .
Os problemas começam quando o número de usuários excede 90. Se formos ao nosso servidor via ssh e examinarmos esse momento na lista de processos usando o comando top, classificados usando Shift + M (pela quantidade de memória consumida), veremos algo assim:
Vemos que o processo apache2 cresceu para muitas subsidiárias e elas consumiram toda a RAM do nosso servidor vps.
Aqui você precisa fazer uma pequena observação. O fato é que, teoricamente, existe um modo para o servidor Apache que permite, em vez desse grande número de processos filho, para cada conexão criar vários chamados multiencadeamentos, cada um dos quais serviria a várias conexões. Esse modo é chamado de
trabalhador , diferente do
prefork padrão. Mas não é fácil instalá-lo, é impossível fazer isso em painéis como o ISP, e se você ficar intrigado e tentar fazê-lo via ssh, acontece que desativar o prefork e ativar o worker não é suficiente, você ainda precisa de uma versão segura do thread do php. E se módulos como Zend ou IonCube forem usados, eles também deverão ser seguros para threads. De qualquer forma, o site oficial do PHP
não recomenda definir este modo.
VPS: CGI
Vamos ver o que acontece ao usar o modo CGI. Para isso, é necessário permitir o uso do PHP no modo CGI no painel de controle do ISP, isso é feito na seção "Contas - Usuários - Configurações para o usuário".
O resultado está disponível
aqui .
Uma imagem sombria acabou. O servidor se recusa a fornecer conteúdo já com mais de 55 visitantes, a RAM é consumida por processos "php". A seguir, é apresentada uma tentativa de restaurar a funcionalidade, mas ainda termina com quase 100% de falha.
VPS: Nginx + PHP-FPM
Chegou a hora de um modo no qual o servidor Apache não é usado, o Nginx funciona e o php é processado pelo módulo php-fpm. Se você usar o painel de controle do ISP, deverá ativar este modo para o usuário. Isso também é feito na seção "Contas - Usuários - Configurações do usuário". Além disso, esse modo deve estar disponível na seção "Configurações - Recursos - Servidor Web (www)".
O resultado está disponível
aqui .
O que você precisa! 100% de disponibilidade, enquanto a velocidade de download e o tempo de resposta do servidor estão em níveis aceitáveis, embora aumentem com o aumento da carga. No entanto, o servidor está lidando!
Vejamos a tabela de processos no momento da carga máxima no servidor:
Vemos que ainda temos um suprimento de RAM disponível. E os processos filhos do php-fpm7.0 não crescem em grandes números, mas são limitados a 5 instâncias, cada uma das quais serve vários threads.
Bem, parece que um "modo vencedor" está definido. Vamos descobrir quantos visitantes simultâneos nosso servidor pode atender nesse modo. Mas antes disso fazemos um pequeno "ajuste". Primeiro, como o apache não é usado para essa operação do servidor, ele pode ser completamente desativado. Faremos isso no painel de controle do ISP, na seção "Sistema - Serviços". Em segundo lugar, mudamos um pouco o princípio de iniciar processos php-fpm. Por padrão, é dinâmico. Isso significa que os processos filhos serão travados na memória, mesmo quando não forem necessários. Ao mesmo tempo, a memória não é liberada e, com o tempo, esses processos podem crescer mais do que gostaríamos. Portanto, propõe-se definir o modo “ondemand” - sob demanda. E defina o número de processos filhos e o tempo limite para eles.
Para fazer isso, você precisará ir ao servidor via ssh e registrar essas configurações no arquivo de configuração php. Isso é feito convenientemente no arquivo para o usuário para quem o domínio foi criado no ISP.
Geralmente está localizado em /etc/php/7.0/fpm/pool.d
Então:
sudo nano /etc/php/7.0/fpm/pool.d/www-root.conf
Por padrão, vemos as seguintes configurações:
[www-root] pm = dynamic pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_children = 5 pm.max_spare_servers = 5
Para ativar o modo ondemand, é necessário substituí-lo por:
pm = ondemand pm.max_children = 5 pm.process_idle_timeout = 10s
E reinicie o php-fpm com o comando
sudo service php7.0-fpm restart
Depois disso, os processos php-fpm7.0 serão criados sob demanda (se houver uma carga), seu número máximo será = 5 e, após 10 segundos de inatividade, o processo será interrompido, liberando RAM.
Por precaução, faremos nosso teste novamente para garantir que toda essa atividade amadora não afete o desempenho do site para pior:
O resultado está disponível
aqui .
Agora vamos executar o Loaddy com muitos visitantes para entender quantas conexões nosso servidor pode suportar:
O resultado está disponível
aqui .
A boa notícia é que todas as solicitações foram processadas, embora com um grande atraso, com um grande número delas por segundo. O tempo de resposta do servidor é próximo de 10 segundos com mais de 190 ocorrências, mas vamos lembrar o gráfico do modo apache, onde já temos 4 segundos de resposta do servidor com mais de 80 usuários, enquanto no modo php-fpm, atrasos semelhantes são observados com 130 solicitações que foram alocadas especialmente cursor no gráfico acima.
Mas este é o mesmo VPS.
Tabela dos principais processos no final do teste (com 200 usuários):
Observe que após o teste, a memória usada pelo pfp-fpm é liberada:
Portanto, nosso servidor está pronto para novas cargas.
Deve-se lembrar que o site opera no modo nginx + php-fpm, o que significa que o apache2 não é usado no trabalho e, como resultado, o .htaccess não é usado. Isso pode não parecer conveniente, mas é a opção mais rápida possível, e os mecanismos de pesquisa classificam melhor os sites que trabalham mais rápido.
Conclusão
Concluindo, mais um pequeno ponto: se você configurou tudo no servidor que desejava e decidiu desconectar o painel de controle do ISP ou ficou sem uma licença para isso, observe que o processo "principal" continuará travado no servidor. Depois de meses, ele pode crescer, então é melhor "matá-lo" e removê-lo da inicialização e do crona.
Se você deseja testar independentemente o site usando o Loaddy ou outros métodos, ele está disponível em
http://130.193.44.219/