Tunando sua aplicação LNMP

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

LNMP???

Acrônimo para:
Linux, NGINX, MySQL e PHP!

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)

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!

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.

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

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!

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!

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”

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

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!

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.

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”.

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.

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

Leandro Mendes
leandro.mendes@dafiti.com.br
@theflockers
linkedin.com/theflockers
github.com/theflockers

Tunando sua aplicação LNMP

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Tunando sua aplicação LNMP

Tunando sua aplicação LNMP