Maximizando o desempenho do PHP 7 com o NGINX, Parte 1: Servidor web e cache

Floyd SmithDiretor de Marketing de Conteúdo

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

O PHP é a forma mais popular de criar uma aplicação Web no lado do servidor, com aproximadamente 80% de participação de mercado. (O ASP.net ocupa um distante segundo lugar, e o Java, um terceiro lugar ainda mais distante.)

O universo PHP inclui uma infinidade de frameworks PHP; entre os mais populares estão Laravel, Phalcon e Symfony 2. O PHP também serve de base para sistemas populares de gerenciamento de conteúdo (CMSs), como WordPress e Drupal. (A versão mais recente do Drupal, o Drupal 8, inclui uma integração significativa com o Symfony 2.

Agora, a equipe do PHP está lançando uma nova versão, PHP 7 — mais de uma década após o lançamento do PHP 5. Durante esse período, tanto o uso da web quanto as exigências impostas aos sites cresceram exponencialmente. O PHP contribuiu para esse rápido crescimento — mas as limitações do PHP também são evidenciadas pelo próprio crescimento que ele possibilitou.

O PHP é geralmente considerado poderoso e flexível, mas sujeito a problemas de desempenho. Sites baseados em PHP podem facilmente “chegar ao limite” após apenas algumas duplicações no volume de tráfego. Assim que um site começa a atingir seus objetivos comerciais ou operacionais, ele passa a ficar indisponível sempre que o volume de tráfego aumenta.

Para milhares e milhares de aplicações baseadas em PHP, algumas mudanças relativamente simples foram suficientes para melhorar o desempenho. Entre elas estão o uso de cache com ferramentas como memcached, o ajuste de bancos de dados e o uso de proxy reverso e balanceamento de carga com NGINX Open Source e NGINX Plus. O NGINX melhorou significativamente a capacidade de resposta das aplicações, permitindo aumentos de ordem de grandeza no número de usuários e no volume de tráfego.

Este post é o primeiro de uma série de duas partes sobre como maximizar o desempenho dos seus sites que usam PHP 7. Aqui, abordamos a atualização para o PHP 7, a implementação do NGINX Open Source ou do NGINX Plus como software de servidor web, a reescrita de URLs (necessária para que as solicitações sejam processadas corretamente), o armazenamento em cache de arquivos estáticos e o armazenamento em cache de arquivos dinâmicos (também chamado de cache de aplicações ou microcache).

No próximo post do blog, abordaremos as medidas que você pode adotar com servidores adicionais: adicionar um servidor proxy reverso, migrar para vários servidores de aplicativos, distribuir a carga entre vários servidores, oferecer 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 chega ao limite

Por que as aplicações PHP chegam a um limite? Pelo mesmo motivo que qualquer software de servidor de aplicações chega a um limite. Quando uma solicitação de usuário é recebida, o PHP — e o software de servidor web sobre o qual ele é executado — precisa realizar várias tarefas:

• Interpretar a solicitação. Primeiro, o software do servidor web e, em seguida, o PHP precisam iniciar processos para receber, interpretar e atender à solicitação. O Apache HTTP Server, por exemplo, aloca recursos para processar cada solicitação de dados, seja ela simples (recuperar um arquivo JPEG) ou complexa (processar solicitações CSS aninhadas). Tudo isso consome tempo, recursos do sistema e memória – que pode ser bastante elevada se o sistema operacional, o PHP ou ambos precisarem carregar várias bibliotecas antes mesmo de começar a processar a solicitação.
• Lidar com protocolos auxiliares. Se você usa SSL/TLS e/ou HTTP/2, o software do seu servidor web precisa decodificar as solicitações, um processo que pode ser demorado.
• Processar a solicitação. O PHP precisa reunir os recursos necessários para processar a solicitação. Isso pode exigir várias consultas ao banco de dados, chamadas pela Internet a serviços externos e um processamento interno complexo.
• Responder à solicitação. O PHP precisa retornar os resultados ao software do servidor web para que sejam enviados de volta ao solicitante como uma resposta HTTP. Lembre-se de que tanto o software do servidor web quanto o PHP mantêm uma thread ativa e dedicada para cada solicitação, desde o recebimento inicial até a confirmação final.

É muita coisa para um servidor físico, uma máquina virtual ou uma instância de servidor em nuvem processar a cada solicitação. O desempenho tende a cair quando a memória física da máquina do servidor — seja ela física ou virtual — se esgota. O servidor então começa a paginar as sessões atuais para o disco à medida que novas solicitações chegam. A espera pelo atendimento das solicitações de arquivos também introduz estados de espera que contribuem para a paginação. Depois de um ponto (bastante 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 descendente que causa longas esperas ou até o encerramento das sessões de usuários frustrados.

Como solucionar problemas de desempenho

Superar as barreiras de desempenho do PHP é certamente possível, e isso exige várias etapas complementares. Cada etapa pode ser combinada com as demais. Em linhas gerais, elas incluem:

• Resolver o problema adicionando mais hardware. 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 uma forma rápida, embora pouco refinada, de resolver problemas de desempenho. Essas soluções podem preservar a disponibilidade ou permitir que o desempenho seja escalado linearmente.
• Aprimoramento do PHP e do código da aplicação. Novas versões do PHP, novos frameworks e melhorias no código da aplicação podem ajudar muito. Além disso, é possível duplicar ou até quadruplicar o desempenho sem gastos adicionais com novo hardware.
• Software de servidor aprimorado. A maioria dos servidores web e o PHP aloca recursos dedicados a cada solicitação aberta em andamento. O software de servidor NGINX processa as solicitações à medida que chegam, sem ocupar recursos desnecessariamente, minimizando o consumo de recursos do servidor.
• Implementação com vários servidores. Você pode implementar um servidor proxy reverso para processar solicitações da Internet e distribuí-las (balancear a carga) entre um ou mais servidores de aplicativos. O servidor proxy reverso também pode gerenciar o cache de arquivos, o encerramento de protocolos como SSL/TLS e HTTP/2 e vários servidores de aplicativos. Mesmo com apenas um servidor de aplicativos, isso reduz grande parte da carga de trabalho dele. À medida que mais servidores são adicionados, o balanceamento de carga garante que nenhum deles fique sobrecarregado com uma parcela da carga maior do que deveria.

Você não precisa implementar essas etapas em uma ordem específica. Por exemplo, mesmo que mantenha o Apache como servidor web e não atualize o servidor de aplicações para o PHP 7, a simples implementação do NGINX como proxy reverso “à frente” dos servidores existentes melhora o desempenho e permite implementar vários servidores de aplicações em paralelo.

Independentemente de como você decida proceder, o principal a ter em mente é que é possível multiplicar o desempenho e até aumentar a capacidade em uma ordem de grandeza, com pouca ou nenhuma alteração no código atual da sua aplicação. Continue lendo para ver como outras pessoas já alcançaram — ou estão em vias de alcançar — esses extraordinários ganhos de desempenho.

Observação: Há uma otimização com vários servidores que não abordaremos em detalhes nestas publicações do blog. Um servidor de banco de dados separado e uma rede de distribuição de conteúdo (CDN) podem reduzir a carga do servidor de aplicações e melhorar muito o desempenho; esses tipos de alterações são independentes e complementares às melhorias na aplicação e na implementação descritas aqui.

Dica 1 – Atualize para o PHP 7

O principal motivo para atualizar para o PHP 7 o quanto antes é simples: a velocidade das aplicações (possibilitada, em grande parte, pela economia de memória). Diz-se que o PHP 7 é duas vezes mais rápido que as versões anteriores do PHP e que usa consideravelmente menos memória. (Sem dúvida, os resultados podem variar em ambos os aspectos.)

O tempo de resposta é, simplesmente, crucial para aplicações web. Uma aplicação web mais rápida — que também usa menos memória, reduzindo a probabilidade de paginação e dos problemas de desempenho resultantes — proporciona três benefícios:

1. Deixa os usuários mais satisfeitos e mais propensos a visitar seu site e realizar tarefas nele, como ler artigos, obter informações sobre produtos, chamar um transporte, alugar um quarto disponível ou fazer compras. Ou seja, os motivos pelos quais você criou o site ou aplicativo em primeiro lugar.
2. Permite que um determinado servidor ofereça suporte a mais usuários sem correr o risco de ficar lento ou até mesmo parar de funcionar devido ao aumento no número de usuários. Adiar o desastre é sempre uma coisa boa.
3. Torna seu servidor menos vulnerável a ataques de hackers que o sobrecarregam para tirá-lo do ar. Hoje em dia, todos são atacados, mas os mais vulneráveis sofrem mais ataques e de forma mais agressiva. Portanto, reduzir a vulnerabilidade pode ser exponencialmente melhor do que aumentá-la.

Todos esses são excelentes motivos para fazer a atualização; considerados em conjunto, os argumentos a favor dela parecem quase irrefutáveis. E “atualize 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 evidente. Então, por que nem todo mundo atualiza imediatamente?

Atualizações segundo o xkcd

É simples: as pessoas detestam mexer em código antigo, e com razão. Se um aplicativo antigo funciona bem o suficiente e os desenvolvedores obtêm melhores resultados criando novos aplicativos do que atualizando os antigos, o aplicativo antigo pode continuar existindo, sem alterações, por muito tempo. (Consulte a segunda publicação desta série no blog para saber como usar o NGINX para melhorar o desempenho do seu aplicativo sem fazer nenhuma alteração no servidor web e no aplicativo atuais.)

Mas, se possível, a opção mais eficiente é começar sua busca por um melhor desempenho atualizando para o PHP 7. No entanto, não comece até ter tempo suficiente para concluir o processo, principalmente sem economizar nos testes.

Vamos ver o que é necessário para atualizar para o PHP 7:

• Alterações na avaliação de expressões. Talvez seja necessário alterar a forma como algumas expressões são escritas para que sejam avaliadas corretamente no PHP 7. (Ou, se você estiver sendo muito cuidadoso e não estiver atualizando todos os seus servidores PHP de uma só vez, para que sejam avaliadas corretamente tanto no PHP 5.6 quanto no PHP 7.) Se você tiver variáveis variáveis ou propriedades variáveis, precisará revisar o código para que elas sejam avaliadas da mesma forma nas duas versões do PHP.
• Alterações de sintaxe. O PHP 7 não oferece suporte a tags ASP ou script. Não é possível ter vários casos padrão em uma estrutura switch. (Deixamos de lado a controvérsia sobre switch versus if-then-else.)
• Remoção de funcionalidades obsoletas. Todo tipo de recurso que foi descontinuado em várias versões 5.x do PHP agora está mais morto do que um papagaio morto. Esses recursos simplesmente não funcionam no PHP 7. Se estiverem no seu código e você tentar remover todos eles, mas não conseguir, pode ter certeza de que o carrinho de compras deixará de funcionar às 23h59 da véspera da Cyber Monday.
• Novos recursos. O PHP 7 adiciona vários recursos novos para atrair quem estiver atualizando código antigo, mas tenha cuidado ao adicionar novos recursos durante uma limpeza de código. Muitas vezes, os novos recursos são excelentes — caso contrário, não teriam sido adicionados —, mas também são ímãs para bugs (seus e de terceiros) e para futuras revisões à medida que o PHP recebe novas atualizações.
• Revisão geral do código. Sempre que você mexer no código — aliás, sempre que abrir um arquivo de código e não tiver certeza se o alterou ou não —, é realmente necessário revisar tudo o que há nele, principalmente o que você alterou.
• Testes. Tudo precisa ser testado o tempo todo. Se você fizer alguma alteração, precisará testar tudo novamente, e ainda assim isso não significa que encontrará todos os bugs. Um ambiente de DevOps bem implementado pode tornar esses testes relativamente fáceis, mas, até hoje, poucos de nós vivem nessa terra prometida.

Este blog da Engine Yard apresenta bons exemplos da maioria desses problemas.

Se você decidir seguir em frente e atualizar para o PHP 7, considere fazer uma análise completa do desempenho e revisar seu código — ou, pelo menos, os recursos críticos dele — aproveitando as novidades do PHP 7. Não há maneira melhor de você e sua equipe aprimorarem suas habilidades, e as alterações que fizerem, revisarem e testarem hoje provavelmente serão úteis por muitos anos. Você também aproveitará ao máximo as outras sugestões de desempenho desta publicação, pois um código otimizado se beneficia muito quando é executado em um ambiente otimizado.

Portanto, apesar de os sites frequentemente implantarem o NGINX para obter melhor desempenho sem alterar o código da aplicação, recomendamos que você tome as rédeas e siga em frente. Há muita ajuda disponível para fazer a migração, ou você pode simplesmente arregaçar as mangas e fazer isso por conta própria. Há um guia de migração para o PHP 7 no site oficial do PHP e um livro prático sobre como atualizar para o PHP 7 da O’Reilly.

Dica 2 – Escolha entre NGINX Open Source e NGINX Plus

O NGINX é o software usado por mais de 140 milhões de sites, incluindo metade dos 10.000 sites mais acessados. (Essas medições detectam o servidor web em sites com um único servidor e o servidor proxy reverso em sites com vários servidores.) Como servidores web, ambos oferecem um aumento imediato de desempenho — em alguns casos, quando um servidor que executa outro software está sobrecarregado e em paginação excessiva, o desempenho pode aumentar em até 10 vezes. Como servidores proxy reversos, ambos permitem o uso de vários servidores dedicados para expandir uma implantação conforme necessário.

Tanto o PHP quanto o Apache alocam recursos para cada solicitação aberta; se um deles ou ambos precisarem 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 software de servidor web elimina esse problema no nível do servidor. Usar os recursos do NGINX para transferir tarefas para o servidor web (como servir arquivos estáticos) ou para um servidor proxy reverso (todos os tipos de cache, encerramento de protocolo, balanceamento de carga etc.) minimiza o trabalho que o PHP precisa realizar, simplificando e acelerando o processamento da aplicação.

Se você usa módulos personalizados ou proprietários do Apache em seu site, talvez não seja possível substituir o Apache pelo NGINX até que esses módulos sejam substituídos. Consulte a NGINX para verificar se há soluções alternativas simples; caso contrário, estime o tempo e o esforço necessários para realizar a mudança.

Depois de decidir usar o NGINX, você poderá escolher entre o NGINX Open Source e o NGINX Plus. Alguns dos recursos mais importantes que o NGINX Plus oferece 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 podem ser adicionados e removidos em tempo real. (O NGINX Open Source está disponível como código compilado e não compilado.) É possível fazer uma ampla variedade de alterações de configuração sem reiniciar o servidor.
• Suporte. O NGINX Plus inclui um pacote de suporte, que oferece acesso direto aos engenheiros da NGINX.
• Monitoramento e gerenciamento. Ferramentas compatíveis com DevOps ajudam a manter seu servidor em funcionamento para cumprir os acordos de nível de serviço (SLAs).

Como servidor proxy reverso, o NGINX Plus oferece vantagens adicionais:

• Balanceamento de carga. Ambas as versões do NGINX oferecem suporte ao balanceamento de carga HTTP básico, mas o NGINX Plus acrescenta algoritmos mais sofisticados e balanceamento de carga TCP.
• Persistência de sessão. Além do balanceamento de carga, o NGINX Plus oferece uma persistência de sessão mais sofisticada, muitas vezes altamente relevante para servidores de aplicações PHP.
• Monitoramento e gerenciamento. Toda a gama de recursos de monitoramento e gerenciamento do NGINX Plus entra em ação em uma implantação com vários servidores; o valor do código pré-compilado e do suporte também é maximizado em implementações mais complexas.

Tanto o NGINX Open Source quanto o NGINX Plus oferecem suporte a cache de conteúdo e microcache (também chamado de cache de aplicações). O cache é útil no contexto do servidor web, pois reduz a carga do servidor de aplicações, embora ambas as funções ainda compartilhem uma única máquina física ou instância de máquina virtual. Em um servidor proxy reverso, o cache pode reduzir significativamente a carga de trabalho do dispositivo que hospeda o servidor de aplicações, proporcionando maiores ganhos de desempenho.

Você pode baixar o software NGINX Open Source diretamente em nginx.org, onde também encontrará o suporte da comunidade. Para iniciar uma assinatura individual do NGINX Plus, inscreva-se para uma avaliação gratuita de 30 dias ou compre online. Para pacotes com várias instâncias, entre em contato com a equipe de vendas da NGINX.

Dica 3 – Converta a configuração do Apache para a sintaxe do NGINX

Ao migrar do Apache para o NGINX como software de servidor web, você precisa fazer algumas alterações, 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 (em vez do Apache) deve usar para a configuração.
• Altere as permissões de leitura/gravação. Adicione permissão à sua conta para realizar operações CRUD (Criar, Ler, Atualizar e Excluir) nos arquivos do diretório raiz do site.
• Especifique padrões de busca válidos. Adicione um bloco location para especificar quais padrões o NGINX pode ou não testar durante o processamento das solicitações.
• Substitua o código de configuração do .htaccess. Os detalhes de configuração do Apache geralmente ficam em arquivos .htaccess ou em arquivos de configuração estáticos (mod_rewrite diretivas, por exemplo). Substitua-os pelas especificações de configuração correspondentes nos arquivos de configuração do NGINX. Para ver alguns exemplos, consulte nosso blogue.

Fazer essas alterações ajuda você a se familiarizar com o NGINX e prepara você para otimizar sites mais complexos, conforme descrevemos na Parte 2 desta publicação do blog. No entanto, se essas alterações de configuração exigirem uma quantidade inaceitável de trabalho ou representarem um grau de risco inaceitável para as operações do seu site, não se preocupe: você pode implementar as arquiteturas com vários servidores descritas na Parte 2 sem substituir o Apache, o software principal do servidor web, e, portanto, sem alterar os arquivos de configuração do servidor web.

Dica 4 – Implemente o cache de arquivos estáticos

Arquivos estáticos são simplesmente arquivos que não mudam com frequência, pelo menos no contexto de servidores web. Em geral, eles incluem arquivos gráficos, como JPEGs e PNGs, e arquivos de código, como CSS e JavaScript. Se você colocar esses arquivos no servidor de aplicações ou em um servidor de banco de dados separado, as solicitações precisarão ser processadas pelo código da aplicação, com toda a sobrecarga necessária para fazer e atender uma solicitação. Isso “desvia” o servidor de aplicações de tarefas mais importantes e pode aproximá-lo do ponto em que a memória física fica sobrecarregada e novas solicitações fazem com que as solicitações em andamento sejam transferidas para o disco.

O cache de arquivos estáticos é uma função essencial 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 reduz a carga do servidor de aplicações; os arquivos são recuperados mais rapidamente e com um consumo de memória muito menor. No entanto, a recuperação dos arquivos ainda é realizada no mesmo servidor físico ou na mesma instância de servidor virtual, portanto, o processador do servidor ainda precisa lidar com outras tarefas além de executar sua aplicação.
• Um servidor proxy reverso NGINX é executado em uma máquina ou instância diferente do servidor web, portanto, o armazenamento em cache de arquivos estáticos não consome recursos dos servidores de aplicação. Assim, o servidor de aplicação pode se concentrar exclusivamente na execução da sua aplicação.

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

• Especificar o diretório raiz para as buscas.
• Processamento de solicitações.
• Otimizando a velocidade de resposta.

Em um servidor web NGINX, sem o uso de um servidor proxy reverso, não há armazenamento em cache no sentido convencional. Basta redirecionar as solicitações de arquivos estáticos para o servidor web usando o cabeçalho X-Accel-Redirect. O servidor de aplicações nunca recebe a solicitação e pode dedicar todos os seus recursos às solicitações da aplicação. Com um servidor proxy reverso, o cache de arquivos estáticos é utilizado, e o servidor físico ou a instância de servidor virtual que executa a aplicação não participa do processamento das solicitações de arquivos estáticos.

Como exemplo de otimização da velocidade de resposta, o trecho de configuração a seguir permite que o NGINX use a chamada de sistema sendfile do sistema operacional, o que elimina uma etapa da transmissão ao evitar que o arquivo seja copiado para um buffer intermediário:

location /mp3 {    sendfile           on;
    sendfile_max_chunk 1m;
    # ...
}

Para obter detalhes sobre como configurar o NGINX para armazenamento em cache de arquivos estáticos, consulte o Guia do Administrador do NGINX Plus.

Dica 5 – Implemente o microcache

De forma um tanto confusa, o microcache é conhecido por vários nomes, entre eles cache de aplicações e simplesmente cache. Aqui na NGINX, usamos o termo microcache para enfatizar o curto período de validade desses arquivos.

Digamos que você tenha uma página de postagem de blog que permita aos usuários fazer comentários. Você quer incluir os comentários mais recentes sempre que um novo visitante acessar a página — ou sempre que os usuários atuais atualizarem a página para ver um novo comentário, seja deles mesmos ou de outra pessoa. Nesse caso, parece uma boa ideia gerar a página novamente a cada visita.

No entanto, fazer isso “todas as vezes” pode se tornar oneroso. Se uma página recebe uma visita por segundo, faz sentido gerá-la novamente a cada visita. Mas, se a página recebe dez, cem ou mil visitas por segundo, além das visitas a todas as outras páginas do site, o servidor da aplicação pode ficar sobrecarregado. Assim, ao tentar oferecer conteúdo atualizado aos usuários, acaba-se impedindo que todos recebam qualquer conteúdo rapidamente.

O microcache consiste em gerar uma página uma única vez e marcar a versão armazenada em cache como válida por um breve período — digamos, um ou alguns segundos. Quando a versão em cache expira, a próxima solicitação aciona a geração de uma nova página, e as solicitações feitas logo em seguida recebem a versão armazenada em cache. Esse é o mesmo comportamento de um arquivo estático, mas em intervalos de tempo muito menores.

Esta imagem indica onde procurar, no seu site, conteúdo que pode ser armazenado em microcache. Ela foi extraída de uma publicação no blog sobre microcache escrita por Owen Garrett, da nossa equipe.

Grande parte do conteúdo dinâmico é adequada para microcache

O microcache é incrível porque reduz a carga de trabalho do servidor de aplicações justamente quando isso é mais necessário, com pouco ou nenhum impacto negativo para o usuário. Ele é tão incrível que já vem integrado a alguns sistemas. O Drupal considera seus recursos robustos e integrados de microcache tão essenciais que, no universo do Drupal, o microcache é chamado simplesmente de “cache”.

Mas a solução do Drupal deixa um pouco a desejar, assim como qualquer solução semelhante. O servidor de aplicações trabalha menos, mas ainda é o Drupal (ou, de modo mais geral, o PHP) que precisa gerenciar a configuração, a implementação e a entrega de arquivos. Ao usar o NGINX para microcache, o servidor de aplicações fica totalmente livre de qualquer tarefa, exceto gerar uma página atualizada na frequência definida pelo microcache. Ele nem sequer recebe as outras requisições, muito menos precisa armazenar ou recuperar qualquer conteúdo quando há acertos no cache.

Usando o NGINX Plus ou outras ferramentas, você pode monitorar seu site e identificar quais páginas se beneficiarão do microcache. O trecho de configuração a seguir implementa um período de cache de 1 segundo para respostas com o código de status 200 OK.

proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inactive=600s max_size=100m;server {
    proxy_cache cache;
    proxy_cache_valid 200 1s;
    # ...
}

Conclusão da Parte 1

Esta primeira parte do nosso post sobre PHP se concentra em soluções de servidor único e em cache, que é eficaz em implementações de servidor único, mas ainda mais quando há um servidor proxy reverso envolvido. A Parte 2 descreve os benefícios de implementar vários servidores e um servidor proxy reverso em torno da sua aplicação PHP.

Para experimentar o NGINX Plus, comece hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.

Sobre o autor

Floyd SmithDiretor de Marketing de Conteúdo

Mais publicações de Floyd Smith