[PHP Conference] Otimizando sua aplicação em PHP com cache de bytecode

Transcript

1. Otimizando sua aplicação PHP em produção com cache de bytecode PHP 5 PHP 7 PHP 8 + CACHE
2. Renan H. Delmonico ➔ 29 anos ➔ Graduado em Sistemas de Informação (Unipar) ➔ Especialista em desenvolvimento web e mobile (Alfa Umuarama) ➔ Desenvolvedor há mais de 10 anos ➔ Engenheiro de Software no PagSeguro International (antigo BoaCompra) ➔ Apaixonado por futebol 🌴👍🌍 e esporte eletrônico (CS2) 🔫 @renandelmonico @renandelmonico /renandelmonico /renandelmonico /renandelmonico renandelmonico@gmail.com
3. 80% of performance issues have nothing to do with your server! Fonte: https://www.combell.com/en/performance-team
4. O básico da linguagem
5. Linguagem interpretada
6. “Fire and Forget”
7. Não tem compilação manual
8. PHP under the hood Redundante
9. PHP sem cache PHP bytecode RAM
10. Entendendo o opcache
11. Benefícios do opcache
12. Melhora a performance, pois não precisamos compilar a cada request
13. O código em produção não muda, a menos que você faça uma nova entrega
14. Existe desde o php 5.5 PHP 5.5 Opcache é lançado 20 de junho de 2013 PHP 8 PHP 9 PHP 7.4
15. Desenvolvido pela Zend
17. Zend Opcache ➔ Várias funcionalidades, dentre elas ele remove o “código morto” ➔ Não são somente configurações, também é possível fazer scripts para gerenciar o cache pois o opcache possui algumas funções que podem ser usadas ◆ https://php.net/manual/en/ref.opcache.php
18. PHP 7.4 e o preloading PHP 5.5 Opcache é lançado 20 de junho de 2013 PHP 8 PHP 9 PHP 7.4 Preloading 28 de novembro de 2019
19. PHP 8 e o JIT PHP 5.5 Opcache é lançado 20 de junho de 2013 PHP 8 PHP 9 PHP 7.4 Preloading 28 de novembro de 2019 JIT 26 de novembro de 2020 Melhorias no JIT ???
20. PHP 8 e o JIT ➔ Opcache faz com que a obtenção dos opcodes seja mais rápida para execução na Zend VM, o JIT faz com que os códigos sejam executados sem VM 🥰 ➔ Zend VM foi escrita em C e funciona como uma camada entre o opcode e a interpretação do opcode pela CPU, o JIT gera um código compilado em tempo de execução para que o PHP “pule” a Zend VM ➔ Implementação usa a lib DynASM (Dynamic Assembler) ◆ O JIT compiler transforma os opcodes em código de máquina específico da arquitetura da CPU usando o DynASM
21. Como o JIT se comporta? ➔ Compila apenas alguns opcodes que são mais utilizados ◆ Faz um profiling dos opcode executados e verifica quais faz sentido compilar ◆ Ex.: código do framework que estamos usando
22. Instalação e configuração
25. ➔ Número máximo de chaves (e scripts) no hashtable do OPcache. ➔ Valor usado será o primeiro número maior ou igual ao conjunto de números primos [223, 463, 983, 1.979, 3.907, 7.963, 16.229, 32.531, 65.407, 130.987, 262.237, 524.521, 1.048.793] ➔ Valor mínimo é 200 e o máximo é 1.000.000 ➔ Controla quantos scripts PHP podem ser armazenados no OPcache ➔ Um valor maior permite mais scripts, melhorando desempenho, porém consome mais memória opcache.max_accelerated_files=10000
26. ➔ Valor em MB que o opcache pode usar para alocar os scripts em memória ➔ Valor mínimo é 8. Caso seja usado um valor menor, será automaticamente alterado para 8. ➔ Mais memória pode aumentar o desempenho, porém aumenta o uso de recursos. opcache.memory_consumption=128
27. Configurando o preloading
29. Que tranquilo! O JIT deve ser mais complexo…
30. ➔ O JIT é muito benéfico para aplicações que realizam operações intensivas em CPU ➔ É necessário definir a quantidade de memória reservada para o JIT pois, por padrão, ele vem desabilitado ➔ Para aplicações pequenas podemos usar 64MB ou 128MB e para aplicações maiores 256MB, porém cada caso deve ser tratado individualmente ➔ Podemos usar uma aplicação de monitoramento para chegar a um valor ideal, como por exemplo o opcache-gui
31. Mais configurações sobre o JIT
32. ➔ Basicamente (existem outras, mas essa é a principal) essa é a única configuração que você irá alterar ➔ Cada posição desse número tem um significado ◆ É confuso? É. Mas é o que tem pra hoje ◆ De acordo com a lista da RFC, esse é o significado de cada número… ◆ A ordem das tabelas é da direita para esquerda
33. O - Optimization Level 0 don’t JIT 1 minimal JIT (call standard VM handlers) 2 Inline VM handlers 3 Use type inference 4 use call graph 5 Optimize whole script
34. T - Trigger 0 Compile all function on script load 1 Compile function on first execution 2 Profile functions on first request and compile the hottest functions afterwards 3 Profile on the fly and compile hot functions 4 Currently unused 5 Use tracing JIT. Profile on the fly and compile traces for hot code segments
35. R - Register Allocation 0 Don’t perform register allocation 1 Perform block-local register allocation 2 Perform global register allocation
36. C - CPU (specific optimization flags) 0 Disable CPU-specific optimization 1 Enable use of AVX, if the CPU supports it
37. ➔ Reza a lenda que a melhor configuração é a 1255 ➔ A opção opcache.jit é opcional, se não informada será considerado o valor padrão ➔ E qual o valor padrão? ◆ opcache.jit=tracing ➔ Ué, mas não era aqueles numerozinhos que eu não entendi nada? ◆ Depois de aprovada a RFC, chegaram na conclusão que as opções não eram user-friendly, então refizeram tudo adicionaram dois alias que são “traduzidos” para os numerozinho. • opcache.jit=tracing • opcache.jit=function ➔ A diferença entre os dois é que function o JIT irá tentar otimizar somente o código dentro de um escopo de uma única função, enquanto o tracing faz o trace (ah, vá!) toda a pilha para identificar e otimizar o código. ➔ É recomendado o uso do trace, pois quase sempre apresentará resultados melhores
38. opcache-gui
40. Ok, mas o quanto isso melhora nossa app?
41. ~10% ~5% ~60% <20% ➔ 34 instâncias ◆ Escalas constantes (praticamente todo dia) ◆ Era normal chegar em 40 instâncias ◆ Em alguns casos foram necessárias mais de 50 instâncias em grandes eventos ◆ Foi diminuído o número para 24 instâncias e diminuiu demais a necessidade de escala da app
43. É isso! Perguntas? Senão 🔥 no privado @renandelmonico @renandelmonico /renandelmonico /renandelmonico /renandelmonico renandelmonico@gmail.com