BLOG | NGINX

Maximizando o desempenho do PHP 7 com NGINX, Parte 1: Serviço Web e Cache

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Floyd Smith
Floyd Smith
Publicado em 26 de fevereiro de 2016

Introdução – Como o NGINX é usado com PHP

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 o PHP bate na parede

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:

  • Decifre a solicitação . Primeiro, o software do servidor web e depois o PHP precisam iniciar processos para receber, decifrar e agir de acordo com a solicitação. O Apache HTTP Server, por exemplo, atribui recursos para lidar com cada solicitação de dados, por mais simples (recuperar um arquivo JPEG) ou complexa (processar solicitações CSS aninhadas). Tudo isso leva tempo, recursos do sistema e uma alocação de memória – que pode ser bem grande se o sistema operacional, o PHP ou ambos tiverem que carregar várias bibliotecas antes mesmo de começar a processar a solicitação.
  • Lidar com protocolos de suporte . Se você executar SSL/TLS e/ou HTTP/2, seu software de servidor web terá que decodificar solicitações, um processo que pode consumir muito tempo.
  • Atue de acordo com a solicitação . O PHP precisa reunir os recursos para lidar com a solicitação. Isso pode exigir várias chamadas de banco de dados, chamadas pela Internet para serviços externos e processamento interno complicado.
  • Responder à solicitação . O PHP precisa retornar os resultados ao software do servidor web para transmissão de volta ao solicitante como uma resposta HTTP. Lembre-se de que tanto o software do servidor web quanto o PHP executam um thread ativo e dedicado para cada solicitação, desde o recebimento inicial até a confirmação final.

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.

Resolvendo problemas de desempenho

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:

  • Jogando hardware no problema . Mais memória, mais memória, discos mais rápidos, servidores de banco de dados separados, uma rede de distribuição de conteúdo, maior capacidade de transferência e outras soluções mecânicas são soluções rápidas e sujas para problemas de desempenho. Essas soluções podem preservar o tempo de atividade ou dimensionar o desempenho linearmente.
  • Melhorando o PHP e o código do aplicativo . Novas versões do PHP, novos frameworks e códigos de aplicativos aprimorados podem ajudar muito. Novamente, é possível dobrar ou até quadruplicar o desempenho, sem gastos adicionais com novo hardware.
  • Software de servidor aprimorado . A maioria dos servidores web e PHP atribuem recursos dedicados a cada solicitação aberta em andamento. O software de servidor NGINX processa as solicitações conforme elas chegam, sem ocupar recursos, minimizando o espaço ocupado pelo servidor.
  • Implementação multiservidor . Você pode implementar um servidor proxy reverso para lidar com solicitações da Internet e compartilhá-las (balanceamento de carga) entre um ou mais servidores de aplicativos. O servidor proxy reverso também pode lidar com cache de arquivos, encerramento de protocolos como SSL/TLS e HTTP/2 e gerenciamento de múltiplos servidores de aplicativos. Mesmo com apenas um servidor de aplicativos, isso alivia uma grande parte de sua carga de trabalho. O balanceamento de carga garante que nenhum servidor fique sobrecarregado com mais do que sua cota de carga à medida que mais servidores são adicionados.

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.

Dica 1 – Atualize para PHP 7

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:

  1. Deixa os usuários mais felizes e mais propensos a visitar e concluir tarefas no seu site, como ler artigos, obter informações sobre produtos, pegar um táxi, alugar um quarto vago ou comprar coisas. Ou seja, os motivos pelos quais você criou o site ou aplicativo em primeiro lugar.
  2. Permite que um determinado servidor suporte mais usuários sem correr o risco de ficar lento ou até mesmo quebrar devido a usuários adicionais. Adiar o desastre é sempre uma coisa boa.
  3. Torna seu servidor menos vulnerável a ataques de hackers que sobrecarregam seu servidor e o tiram da produção. Hoje em dia, todos são atacados, mas os fracos são atacados mais e de forma mais agressiva. Portanto, menos vulnerabilidade pode ser exponencialmente melhor do que mais.

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?

Maximizando o desempenho do PHP 7 com NGINX
Atualizações de acordo com xkcd

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:

  • Alterações na avaliação de expressão . Talvez seja necessário alterar a maneira como algumas expressões são escritas para que sejam avaliadas corretamente no PHP 7. (Ou, se você estiver sendo realmente cuidadoso e não estiver atualizando todos os seus servidores PHP de uma vez, para que eles sejam avaliados corretamente tanto no PHP 5.6 quanto no PHP 7.) Se você tiver variáveis ou propriedades variáveis, será necessário revisar o código para que elas sejam avaliadas da mesma maneira em ambas as versões do PHP.
  • Alterações de sintaxe . O PHP 7 não suporta tags ASP ou script. Não é possível ter vários casos padrão para um switch. (Deixamos de lado a controvérsia sobre switch versus if-then-else .)
  • Remoção de funcionalidade obsoleta . Todos os tipos de coisas que foram descontinuadas em várias versões 5.x do PHP agora estão mais mortas do que um papagaio morto . Eles simplesmente não funcionam no PHP 7. Se eles estiverem no seu código e você tentar remover todos eles e não conseguir, a funcionalidade do código do seu carrinho de compras certamente desaparecerá às 23h59 da noite anterior à Cyber Monday.
  • Novos recursos . O PHP 7 adiciona uma série de novos recursos para tentar qualquer um que esteja atualizando um código antigo, mas tenha cuidado ao adicionar novos recursos em uma limpeza de código. Novos recursos geralmente são maravilhosos, ou não teriam sido adicionados, mas também são ímãs para bugs (seus e de outros) e revisões futuras à medida que o PHP é atualizado.
  • Revisão geral de código . Sempre que você mexer em código – ou melhor, sempre que abrir um arquivo de código e não tiver certeza se o alterou ou não – você realmente precisa revisar tudo nele, especialmente o que você alterou.
  • Testando . Tudo precisa ser testado o tempo todo. Se você fizer alguma alteração, precisará testar tudo novamente, e isso ainda não significa que você detectará todos os bugs. Um ambiente DevOps bem implementado pode tornar esses testes relativamente fáceis, mas apenas alguns de nós vivemos nessa terra prometida atualmente.

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.

Dica 2 – Escolha NGINX Open Source ou NGINX Plus

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:

  • Código pré-compilado . O NGINX Plus é distribuído em formato compilado, incluindo bibliotecas populares e módulos dinâmicos que você pode adicionar e remover rapidamente. (O NGINX Open Source está disponível como código compilado e não compilado .) Você pode fazer uma ampla variedade de alterações de configuração sem reiniciar o servidor .
  • Apoiar . O NGINX Plus inclui um pacote de suporte , dando a você acesso direto aos engenheiros do NGINX.
  • Monitoramento e gerenciamento . Ferramentas amigáveis ao DevOps ajudam você a manter seu servidor ativo e funcionando para atender aos acordos de nível de serviço (SLAs).

Como um servidor proxy reverso, o NGINX Plus tem vantagens adicionais:

  • Balanceamento de carga . Ambas as versões do NGINX oferecem suporte ao balanceamento de carga HTTP básico, mas o NGINX Plus adiciona algoritmos mais sofisticados e balanceamento de carga TCP .
  • Persistência da sessão . Junto com o balanceamento de carga, o NGINX Plus oferece persistência de sessão mais sofisticada, geralmente altamente relevante para servidores de aplicativos PHP.
  • Monitoramento e gerenciamento . A gama completa de recursos de monitoramento e gerenciamento do NGINX Plus entra em jogo em uma implantação multiservidor; o valor do código pré-compilado e do suporte também são maximizados em implementações mais complexas.

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 .

Dica 3 – Converta a configuração do Apache para a sintaxe 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 :

  • Crie ou converta arquivos de configuração . Altere o código de configuração para especificar quais arquivos o NGINX (não mais Apache) deve usar para configuração.
  • Alterar permissões de leitura/gravação . Adicione permissão à sua conta para realizar operações CRUD (Criar, Ler, Atualizar, Excluir) em arquivos no diretório raiz do site.
  • Especifique padrões de pesquisa válidos . Adicione um bloco de localização para especificar quais padrões o NGINX pode e não pode tentar durante o processamento de solicitações.
  • Substitua o código de configuração .htaccess . Os detalhes de configuração do Apache tendem a ficar em arquivos .htaccess ou em arquivos de configuração estáticos (diretivas 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.

Dica 4 – Implementar cache de arquivo estático

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:

  • Em um servidor web NGINX, o cache de arquivos estáticos alivia a carga do servidor de aplicativos; os arquivos são recuperados mais rapidamente e com muito menos sobrecarga de memória. No entanto, a recuperação de arquivos ainda está sendo conduzida pelo mesmo servidor físico ou instância de servidor virtual, então o processador do servidor ainda é forçado a lidar com outras tarefas além de executar seu aplicativo.
  • Um servidor proxy reverso NGINX é executado em uma máquina ou instância diferente do servidor web, de modo que seu armazenamento em cache de arquivos estáticos não consome nenhum recurso nos servidores de aplicativos. O servidor de aplicativos pode se concentrar exclusivamente na execução do seu aplicativo.

Há três etapas gerais para implementar o cache de arquivos estáticos no NGINX:

  • Especificando o diretório raiz para pesquisas.
  • Processando solicitações.
  • Otimizando a velocidade de resposta.

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 .

Dica 5 – Implemente Microcaching

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.

cacheabilidade-intervalo-estático-dinâmico-personalizado
Muito conteúdo dinâmico é adequado para microcaching

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 200Có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;
# ...
}

Conclusão da Parte 1

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."