PHP / FastCgi - Qual é o limite pelo qual usar nginx em vez de apache

Question

Sou um desenvolvedor PHP, sempre desenvolvi em um ambiente LAMP e tudo correu bem até agora. No momento, estou desenvolvendo um aplicativo da Web em PHP, ainda no apache e sem o uso de nenhum framework.

O PHP-fpm servirá conteúdo dinâmico e estático no front-end, enquanto os scripts php-cli serão executados no back-end por meio de alguns cron-jobs (o aplicativo real).

Desta vez, estou enfrentando o problema de simultaneidade porque esse site será usado por vários usuários. O número estimado de usuários logados simultâneos é de 50 a 75, pelo menos para o período de inicialização.

Eu li em quase todos os lugares que o Nginx é melhor que o Apache nesse tipo de trabalho; Eu li um monte de artigos que explicam as diferenças entre eles, eu li estatísticas de desempenho, mas em nenhum lugar eu encontrei o limite real (de usuários simultâneos) sobre o qual você deve mudar de Apache para Nginx.

Eu estou querendo saber isso só porque, como eu disse acima, eu sempre trabalhei com o Apache e uma mudança no servidor web é uma escolha significativa, em particular quanto ao tempo que eu vou ter que gastar na documentação do Nginx para entender seu comportamento / funcionalidades. De fato, eu tentei configurar um servidor LEMP, mas o Nginx soa como o árabe para mim no momento.

Após essa breve introdução, aqui estão minhas perguntas:

1. Qual é o limite recomendado (número de usuários) sobre qual alternar para o Nginx?
2. Assumindo que o meu site nunca terá mais de 300 usuários on-line ao mesmo tempo, eu realmente tenho que gastar semanas para estudar o Nginx, mesmo que seja um pouco mais rápido na veiculação de conteúdo?
3. Existem diferenças significativas em termos de segurança entre o Apache / PHP-fpm e o Nginx / PHP-fpm?
4. Por último, mas não menos importante: acabei de mudar da OVH para a Digital Ocean. Oceano Digital parece fantástico. Eles fornecem imagens pré-construídas de um servidor LEMP. Quanto posso confiar nas configurações de segurança do Nginx da Digital Ocean? Eu pergunto isso só porque eu procurei muitas dicas de hardening para o Nginx, e a maioria delas é executada antes de construir o próprio Nginx. Qualquer pessoa que esteja usando o servidor LEMP da Digital Ocean pode me ajudar?

NOTA: imagino que esta informação seja importante para responder: Prod. servidor (no tempo de inicialização) será: 4c / 8t intel - 8gb RAM - disco rígido SSD

Muito obrigado.

    

Answer 1

Primeiro, 50 a 75 usuários simultâneos não são nada - o servidor da Web pode lidar com isso em uma configuração padrão, totalmente não otimizada, e você não precisa se preocupar até adicionar um zero (ou dois) ao final desse número.
Se você está tendo problemas de desempenho nesse nível, é provável que seu problema esteja em outro lugar (banco de dados, código do aplicativo).

Dito isso, não há nenhum valor mágico de "limiar" para considerar fazer uma alteração arquitetônica - na verdade, não há razão para alguma vez mudar se você não quiser: se você estiver familiarizado com o Apache, você pode querer ficar com ele para facilitar a administração e resolver seus problemas de carga, adicionando mais servidores para distribuir a carga de trabalho.

Se você deseja otimizar o desempenho, você deve basear sua decisão no desempenho. Ajuste seus servidores da melhor maneira possível ( veja aqui para o Apache 2.2 ou aqui para o Apache 2.4 ou aqui para o nginx ) e, em seguida, faça o teste de carga para determinar que tipo de desempenho cada design lhe dará.

Se os números de referência estiverem próximos, não importa qual servidor web você usa porque o afunilamento está em outro lugar em seu design (e seu teste deve mostrar onde está o afunilamento para que você possa trabalhar nessa parte específica do sistema) .

Se os números forem radicalmente diferentes, você pode usar o servidor web mais rápido para evitar a necessidade de adicionar mais hardware, mas em algum ponto você precisará adicionar mais máquinas para lidar com alta simultaneidade - isso é apenas o caminho da web.

Finalmente, lembre-se de que todas as vezes que você otimizar prematuramente Knuth mata um gatinho , todas as vezes que você otimizar prematuramente Knuth, ele mata um gatinho. Ele estava falando de otimização prematura na programação, mas é axiomático para a administração do sistema e também para o design da infraestrutura: Se você não precisa de maximizar o desempenho imediatamente no lançamento implante o que você sabe (e o que você) testado), e incrementalmente melhorar o desempenho mais tarde.