 Bom dia pessoal, nome é Alessandro, eu trabalho na King Host, como analista de infra-senior. E hoje vou trazer para vocês que muitos devem ter curiosidade de saber que ocorre por trás de uma infraestrutura para hospedar o WordPress, mas tem medo de saber ou não sabem para quem perguntar. Primeiro vou fazer uma short build. Eu também sou formado em MBA, Ingestão Estratégica da TI, pela fchv. E me formei engenharia de computação na FURG em Rio Grande, para quem é gaúcho, passa confusão entre FURG e orgs, principalmente de fora do estado. Eu sou apaixonado por performance, Tannin de Ambientes Linux, meu core, é o que me motiva. Sou pai de um filho de dois anos e oito meses, o Enzo e Grêmio Estão. Então, o que nós vamos ver hoje? Nós vamos ver um pouco de várias formas de se montar uma infra, iniciando com a parte PHP, que a maioria deve conhecer. Vamos falar um pouco sobre Inginx, um pouco também sobre Burned Cache, que é um proxy reverso, e como fazer esse cache trabalhar com o SSL. Vou trazer também alguns comparativos de performance entre todos esses cenários que vão ser apresentados. E, no final, algumas dicas para fazer com que vocês tenham uma instalação hortepress mais performática. Então, começando por estruturas de hospedagem hortepress, ou o que está de trás do meu site. Primeiro, vamos pelo mais usual, que é o Apache, PHP e MySQL, a famosa pilha-lamp, que é o que a maioria do mercado oferece. Se você for na King Host, na local Web, na Blue Host, etc., você vai encontrar e contratar um site, e vai ser esse tipo de ambiente que você vai ter no ambiente de hospedagem compartilhada. Ele também é facilmente usado em ambientes de desenvolvimento, no Linux. Ele é bastante fácil de usar e configurar, e tem pasta documentação pela internet. Então, qualquer pesquisa no Google, aprende a configurar um Apache com PHP e MySQL. Basicamente, é esse o cenário que vocês têm, o usuário final. Ele vai acessar o seu servidor Apache, que vai servir o seu conteúdo estático. E o que for dinâmico, ele vai passar para o PHP através de um módulo do próprio web server. E se pressar alguma requisição de banco de dados, no caso do hortepress, que usa bastante banco de dados, ele redireciona para o servidor MySQL, que pode estar na mesma máquina ou em uma máquina remota, seja dentro da rede local ou fora da tua rede. Mas também nós temos um outro cenário que agora está entrando bastante forte, que é o uso do PHP-FPM, ou seja, é o PHP rodando como um serviço separado do Apache. Por que é isso? Ele te provê um isolamento de pools, cada site pode ter sua própria pool de processos, e o Apache fica responsável só pelo conteúdo estático. Naquela ponte entre o Apache e o PHP, tem um módulo chamado modproxyf, que é por onde ele repasse as informações para o PHP propriamente títido processar. Agora, afançando um pouco o nível, nós vamos introduzir o Nginx, que é um web server russo, que é usado na maioria dos grandes sites, top Alexa no mundo inteiro, e com o PHP-FPM e o MySQL e MariaDB, ele forma a pilha LEMP. Ele é um web server mais avançado, que exige mais conhecimento de configuração. A documentação já não é tão vasta, agora tem bastante documentação, antes será bem mais difícil, mas ela é muito mais performático que o Apache em diversos cenários, e no final da apresentação, vocês vão ver os números e entender o que estou falando. Por isso, ele é bastante utilizado para ambientes de hospedagem especializada do WordPress. E ele usa necessariamente o PHP-FPM para fazer o processamento dos scripts, PHP, que é o cenário que eu apresentei anteriormente, só que no lugar do Apache para servir o conteúdo, tem o Nginx. Ele também suporta cache de conteúdo, configurações mais avançadas, consegue fazer cache de scripts PHP. Ele é bem performático, bem interessante. Agora vamos fazer um pouco mais do nível e colocar um proxy reverso na frente para fazer o cache estático. Normalmente o que nós fazemos em instalações WordPress? Nós instalamos um plugin de cache, um W3 TotalCache, WP SuperCache, para gerar um cache de conteúdo dentro do seu FTP. E com regras de rewrite, ele fornece o conteúdo estático previamente cacheado para o cliente final. O Varnish faz isso, ele é um servidor que faz isso, mas não manda isso em memória. Toda a requisição vai ser atendida por ele, ele não vai ter, ao invés de ter o Apache, o Nginx na frente, vai ser o Varnish que vai atender as suas requisições de cliente. E se o conteúdo estiver em cache, ele que vai servir essa requisição para ti. Se não tiverem cache, ele vai dizer, opa, eu não tenho esse conteúdo comigo, eu vou reccitar para o meu web server. Então o Apache ou o Nginx vão atender a solicitação. Esse gráfico aqui. O armazenamento desse cache pode ser feito de duas formas. O padrão é fazer em memória, porque ele é mais performático, ele entrega muito rápido por acessar uma memória que é muitas vezes mais rápida que o teu disco local, ou em disco, se você está, por exemplo, no VPS, não tem muito recurso, pode manter seu cache em disco sem nenhum problema. Agora, no caso do WordPress, nós temos a área administrativa, nós precisamos fazer login. E a gente não quer que a nossa sessão seja mantida para, seja feito cache desse teu login. Por exemplo, se eu fizer login e eu não isolar esse cache, uma outra máquina em outro lugar do mundo vai acessar a sua sessão administrativa. Isso ninguém quer. Então, nesses casos, o WordPress pode ser instruído a não efetuar cache. Então, WP login.php, o RLs que iniciam com WP admin, estou excluído cache. Ou, com configurações mais avançadas, pode usar cookies para fazer com que o cache seja gerado separadamente, usando a plenitude. Mas ainda tem a questão do SSL. A gente sabe que hoje o Google ranqueia melhor que utiliza SSL no seu site, mas eu quero usar cache e eu quero usar o varnish, ou algum outro proxy-reverso que use a nossa cache de conteúdo. Como eu vou fazer? O varnish não suporta. Isso foi uma escolha do time de desenvolvimento do varnish, que não vê necessidade de implementar esse suporte, e por isso tem um carinho que é chamado no termo técnico de terminação SSL, que é nada mais nada menos que um web server na frente do varnish, que só vai tratar requisição HTTPS. E esse web server vai fazer um proxy para o varnish, que é ali a seta em verde. Ele requisita, necessariamente, vai fazer o proxy da conexão criptografada para o varnish. Se o cache estiver ali, ele já atende a requisição, passa para o cliente, tudo criptografado. A comunicação entre essa terminação SSL e o varnish, ela é feita via HTTP. Não segue via HTTPS para ser mais performático. Se não tiver, segue o processo normal de como é com o varnish na frente, se a tua solicitação for direto pela porta 80, o varnish faz o atendimento dessa questão. Aí vocês devem estar curiosos. O que tudo isso faz de diferença no meu site? Então, vamos colocar isso na prática. Eu conduzi alguns testes com o meu blog pessoal. Deixa eu mostrar aqui para vocês. É uma instalação WordPress bem simples. Tem uma página inicial, que é o meu currículo, e tem uma sessão que é um blog onde eu coloco coisas pessoais, anotações de conteúdo. Então, em cima desse cenário, eu repliquei algumas situações diferentes. Quer usar primeiro o Apache, ou o Nginx junto com PHP-FPM, sem ter o varnish na frente. Um segundo cenário adicionando o varnish e o terceiro adicionando a terminação SSL. E foi feito um teste bem simples na máquina local, rodando o Apache PaintMark, no binário AB, que vem no pacote Apache Utils, no Linux. E esses foram os resultados. Primeiro, trazendo o tempo total de teste. É um cenário onde foi executado e está a mil requisições com diferentes números de conexões simultâneas. Vocês podem notar que o Apache com PHP demorou... A primeira execução é sempre mais demorada, até por ser apenas um processo para atender tudo. Você vê que nos demais cenários, com mais processos, se manteve em torno de 33 a 38 segundos, tempo total. E nós colocamos o varnish na frente, chat espenca para 0,17 mil segundos, para atender mil requisições com 100 conexões simultâneas. Com o SSL na frente do varnish, obviamente demora um pouco mais, mas ainda é rápido, 3,8 segundos, porque tem o overhead do SSL. E o número de requisições por segundo, GHC... Os números falam por si só. Enquanto a Apache EngineX com PHP e FPM te atendem entre 33 requisições por segundo, o varnish atende quase 6 mil. E com o SSL 260. É uma diferença brutal. Então, o que eu posso fazer para chegar a esses números além de usar varnish, SSL, etc.? Eu posso turnar o meu sistema operacional, os parâmetros do kernel dele, como, por exemplo, performance de rede, consumo de memória, VM.swapness, evitar que faça swap excessivo, também turning de escalonador de disco. No Apache EngineX, você vai precisar quantificar qual é o seu limite de conexões simultâneas. Principalmente no VPS, você vai ter uma quantidade de memória e processamento finito. E se estou dimensionando isso errado, a sua aplicação vai sofrer. Quando o varnish também foi precisar ajustar o tamanho do seu storage de cache, principalmente ser usado em memória. Então, é bom saber o quanto que consome, quanto que tu ocupa de cache para fazer o redimensionamento correto. PHP também é um ponto importante, sempre usar a última versão disponível, se tem algum plugin que é incompatível com 7.2, tento 7.1, tento 7, tento 5.6, que com certeza vai rodar a maioria das... quase totalidade dos plugins e temas do WordPress, mas não usa a versão descontinuada, é falha de segurança, tu perde performance e a diferença entre, por exemplo, o PHP 5.3 e o 7.2 é brutal, de 30 a 40%. E na parte do FPM, você tem que saber a questão do seu gerenciador de processos ideal para a sua carga. Se você tem um site pequeno, você pode subir os processos por demanda, mas se você tem um site muito grande, talvez queira deixar alguns processos já em espera online para atender rápido. E também tem que saber quantos processos você vai deixar nessa pul para atender os seus clientes. E no WordPress também tem uma série de coisas que podem ser feitas, que é manter apenas plugins e temas ativos. É menos coisa que você tem para carregar, em banco, procurar, substituir plugins que impactam sua performance. Se você não pode usar o Varnish, instala um plugin de cache, vai fazer um bem danado, principalmente no ambiente compartilhado. Redimensiona as suas imagens, os JPNG, JPG, GIF, conforme a tua necessidade de uso. E Disabilita o WP Chrome tem uma diretiva dentro da censurida no WP Config, e adiciona ela como uma tarefa na tua tabela de Chrome Jobs para ser mais performático e desocupar o seu pult processo. Alguma dúvida, pessoal? Comberto a perguntas, então. Oi. Eu... Por que eu utilizaria o Varnish ao invés de um CDN, tipo a Cloudflare, ou alguma coisa que vai deixar meu cache já localizado e bonito de acessar em qualquer lugar do mundo? CDN é também uma boa opção, mas tem pessoas que preferem ou têm a curiosidade de criar seus próprios ambientes, como eu. E mesmo grandes empresas de hospedagem utilizam o Varnish como uma camada de cache em seus produtos do WordPress. E usar o Varnish e usar um CDN são complementares, eles não se excluem. Você pode ter o CDN para ter esse cache geolocalizado, mas você pode ter o Varnish para ter esse dado mais rápido disponível para as localizações do CDN. Aqui, bom dia. Eu entendo, pelo menos o meu ponto de vista, que a performance depende de três sujeitos. Depende do servidor estar OK, do desenvolvedor ter feito o trabalho dele e do usuário também fazer a parte dele. Você concorda com esse ponto de vista e qual desses três sujeitos você acha que tem a maior porcentagem de responsabilidade na performance de um site? É o servidor, é o desenvolvedor ou é o usuário? Qual deles que retenha a maior quantia de responsabilidade no trabalho dele? Eu concordo com a tua afirmação e pela experiência que eu tenho trabalhando com Oort para esse já faz seis anos, atuando na área de suporte quanto de infraestrutura, a maioria da culpa não é o servidor, é o desenvolvedor. Utilizam plugins pouco performáticos, utilizam versões antigas do PHP, mesmo a hospedagem de disponibilizando outras versões mais performáticas. O desenvolvedor não atualiza, normalmente o cliente que contrata o desenvolvedor para fazer seu site, depois de pronto não faz um contrato de manutenção com esse desenvolvedor e o site fica daquele jeito eternamente. Hoje em dia ainda tem a atualização automática do Oort, por exemplo, para manter o core atualizado, mas o restante depende também do ano do site TCO, esse cuidado. Também tem a questão de escala, muitos contratam uma hospedagem de baixo custo querendo que ela vá atender mil conexões simultâneas. Não é assim. Se você quer algo que vá te atender em grande escala, você vai ter que partir para um cloud dedicado, ou para um VPS, ou até uma máquina dedicada. O dono, o mantenedor do site, na maioria das vezes, é o maior culpado. Nós estamos na empresa, com um alo de phase speed que fez bastante a velocidade do acesso ao nosso site. Hoje o nosso site tem média de 100 mil acessos diários, mas nós não usamos o SSL. Queria saber qual é a diferença, se realmente está a diferença na questão do banqueamento do Google, o uso do SSL, e se de repente isso não ia influenciar na velocidade do caiga do site? O Google frequentemente altera as suas políticas de ranking, e há pouco tempo a questão do SSL que está se tornando bem impactante na questão do ranking. Ainda mais com os navegadores te acusando que se tu entra em um formulário, o seu site não é seguro por não ter criptografia. Então, sim, é importante, e sim, tem um impacto adicional no teste. Nós vimos que ele tinha um impacto considerável, cai bastante a performance, porque tem um overhead de criptografais e criptografas desencriptografadas em informação. Mas isso tu pode também ajustar ao seu site que não querem que sejam criptografadas as partes mais privativas dos SSL. Nosso tempo está escotado agora. Eu vou estar no evento todo dia. Caso vocês tenham alguma dúvida, podem me procurar nos corredores. Eu vou estar aberto a perguntas de todos vocês. Obrigado, pessoal.