Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tunando sua aplicação LNMP

Apresentação no DAFITI Tech Day 2014.

  • Be the first to comment

Tunando sua aplicação LNMP

  1. 1. Tunando sua aplicação LNMP
  2. 2. Sobre os palestrantes ● Leandro Mendes – Formado em Redes de Computadores pela Oswaldo Cruz – Atua em TI desde 1998 – Administrando Linux boxes desde 2000 – Imitador oficial do Silvio Santos
  3. 3. LNMP???
  4. 4. LNMP??? Acrônimo para: Linux, NGINX, MySQL e PHP!
  5. 5. LNMP??? ● Linux - dispensa apresentações, certo? ● NGINX (Engine X) – ● ● Em conjunto com outros webservers, foi criado para resolver o “C10k problem” ( http://www.kegel.com/c10k.html) MySQL PHP – php-fpm (FastCGI Process Manager)
  6. 6. Por que NGINX?
  7. 7. Por que NGINX? ● Tem uma BELA lista de features ( http://nginx.org/en/) ● Multiplataforma ● Event-driven ● Extensível através modulos (ngx_lua e ngx_pagespeed, por exemplo) ● FastCGI,wsgi ● Rápido! Mas muito rápido!
  8. 8. Mas e o APACHE?
  9. 9. Mas e o APACHE? ● Eu gosto do APACHE! – O conceito do MPM é interessante: ● Prefork, Worker, Event ● O php só funciona (direito) com o Prefork ● – Em alguns benchmarks se mostra mais rápido que o NGINX+php-fpm, mas nunca vi na prática... É extensível também através de módulos apxs. Comparar NGINX e APACHE é como comparar uma TV de tubo com uma de LED.
  10. 10. APACHE NGINX
  11. 11. PHP-FPM
  12. 12. PHP-FPM ● Alternativa ao php-fcgi e mod_php no apache ● Multiprocesso ● Auto escalável (evil!) ● ● Ideal para webservers como NGINX e Lighttpd Integrado à árvore do projeto PHP
  13. 13. Problemas comuns
  14. 14. Problemas comuns ● Lentidão para acesso ou drops de conexão, sendo que: – Baixíssimo consumo de CPU – Consumo de IO ínfimo – Memória disponível – Baixo consumo de rede veja seus logs! obviamente tem algo errado!
  15. 15. Problemas comuns ● Algumas possibilidades: – Keepalive habilitado – Baixo número de “acceptors” – Número baixo de “workers” do webserver/php-fpm – Limite de “open files” – ip_conntrack – local_port_range – Permissão no filesystem (que coisa!) – Performance do banco de dados – Network stuff (DNS, Link, ativos de rede problemáticos, etc.) – Aplicação!
  16. 16. Fine-tuning!
  17. 17. Fine-tuning ● Linux – max_open_files: ● ● Pode ser ajustar via ulimit -n 8192, ou ● – Pra servidores, de 8192 pra cima! Via /etc/security/limits.conf ip_conntrack: ● ● – Se puder desabilitar, melhor Caso não, deixar o máximo possível, ex: sysctl net.ipv4.netfilter.ip_conntrack_max=65535 local_port_range ● sysctl -w net.ipv4.ip_local_port_range="9000 65535”
  18. 18. Fine-tuning ● Linux – DNS cache (dnsmasq) – Ajuste do TIME_WAIT para conexões expirarem ● ● ● net.ipv4.tcp_tw_recycle = 5 net.ipv4.tcp_tw_reuse = 2 Dica! – Red Hat tuning manual: http://people.redhat.com/alikins/system_tuning.html
  19. 19. Fine-tuning ● NGINX – – worker_connections: número de acceptors. Um bom número, entre 512 e 1024. Mais que isso só se muito necessário. – multi_accept: on – keepalive_timeout: 0 (diferente de zero, somente em casos específicos, onde keepalive é mandatório) – ● worker_process: 1 para cada core físico (core, não thread) Verifique se há necessidade de gerar logs de acesso. Um disco de log local lento pode fazer sua aplicação ficar lenta. Dica! – – ● Habilitar a compactação gzip ajuda a economizar uso de rede! Procure fazer cache de páginas já renderizadas para economizar processamento!
  20. 20. Fine-tuning ● PHP-FPM – – pm.start_servers: Pode variar. O ideal é selecionar um número como 100 (ou 200) e acompanhar como está a criação de novos “childrens” – ● pm.max_children: número máximo de “acceptors” do NGINX pm.max_requests: O seu valor do max_children é o limite aqui. Dicas: – Efetuar code caching, com PHP APC! – Use o módulo proxy_cache do NGINX para evitar processamento desnecessário, cacheando páginas menos voláteis.
  21. 21. Fine-tuning ● MySQL (no ponto de vista de infra-estrutura) – max_connections ● – Depende da quantidade de acessos, perfil de hardware. Innodb-per-file-table ● MySQL é da Oracle mas não é Oracle. Quanto maior do seu datafile ibdata1, pior. – Discos SSD são legais, mas caros. Um RAID10 de pelo menos 6 discos resolve. – Tune suas queries. 90% dos seus problemas estão aí. Bom Disk IO para banco de dados é fundamental! Disco SATA 7.2k é o “fim da picada”.
  22. 22. Mundo real – Black Friday
  23. 23. Mundo real – Black Friday ● Pontos pendentes: – – Uso de CPU em 60% médio – Muitos hits no banco de dados – ● Infra muito enxuta Queries repetidas, queries problemáticas e sem cache Solução – Virtualização (escalando horizontalmente uso médio de CPU em 20%) – CDN externo e cache – Somente INSERTS, UPDATES de DELETES no Master. SELECTS nos Slaves – Aplicação: Removendo queries duplicadas, tuning de queries e aumentando a abrangência do cache (Cache do MySQL e Memcache) – Load balancers everywhere! Aumentando a disponibilidade dos serviços consumidos pelo frontend.
  24. 24. Dúvidas?
  25. 25. Bibliografia ● NGINX Wiki: http://wiki.nginx.org/Main ● The C10K Problem: http://www.kegel.com/c10k.html ● ● ● Red Hat tuning manual: http://people.redhat.com/alikins/system_tuning.html Apache MPM Modules Worker vs Prefork: http://kb.parallels.com/en/113007 Medindo a Black-Friday 2013: http://ale.biancalanas.net/trac-ale/wiki/Medindo-a-BlackFriday-2013
  26. 26. Leandro Mendes leandro.mendes@dafiti.com.br @theflockers linkedin.com/theflockers github.com/theflockers

×