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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Tunando sua aplicação LNMP

Ähnlich wie Tunando sua aplicação LNMP (20)

Tunando sua aplicação LNMP