Tunando sua aplicação LNMP

620 views

Published on

Apresentação no DAFITI Tech Day 2014.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
620
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
7
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

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

×