Clusterização de
   Aplicações
      PHP
    Diego Thomaz Flores
QUEM?
Analista e programador PHP há 8 anos, já
desenvolveu projetos para o Ministério do
Turismo, EMBRATUR, Fundação Getúlio Vargas,
Telefonica e Agência Click e Folha de São Paulo.

É Gerente de Projetos na 3YZ Performance Digital,
em Porto Alegre, agência especializada em
marketing e posicionamento online de marcas.

É responsável pela ECRAYON Tecnologia Criativa,
estúdio de desenvolvimento de sistemas web-
based.
AGENDA

•   Camadas de Execução
•   Webserver
•   Database
•   Codificação
•   Cache
•   Load Balance
•   Client-side scripting
Para fazer uma aplicação rodar bem numa
estrutura clusterizada, ela precisa ser
escrita para uma estrutura clusterizada!
CAMADAS DE EXECUÇÃO
• Conteúdo estático
• Scripts e bibliotecas client-side
• Scripts server-side
• Banco de Dados
• Webserver
WEBSERVER
DISTRIBUIÇÃO DE CONTEÚDO

Diferentes domínios para diferentes tipos de conteúdos
      http://www.exemplo.com        (PHP, dinâmico)
      http://estatico.exemplo.com (imagens, CSS, HTML, documentos)
WEBSERVER
APACHE PREFORK                APACHE WORKER

• Grande consumo de memória   • Menor consumo de memória
• Rápido                      • Apache 2.0+
• Pouco escalável             • Mais escalável
• Até 2 CPUs                  • Multi-thread
                              • 2 CPUs ou mais
WEBSERVER
OUTRAS OPÇÕES: servidores mais leves


  • lighttpd
  • tux
  • thttpd
  • nginx
Aplicações web geralmente não utilizam
processos que comprometam o
processamento, porém geram milhares de
dados e queries.

Dessa forma, em aplicações bem escritas, o
mais provável é que a base de dados entre
em colapso primeiro.
DATABASE
DIMENSIONAMENTO E TIPIFICAÇÃO CORRETA DOS DADOS

   INT, TINYINT, BIGINT, FLOAT, DOUBLE
   CHAR, VARCHAR, TEXT, BLOG



InnoDB vs. MyISAM

   InnoDB -> Foreign Keys, Constraints, Transactions
   MyISAM -> Data storage
DATABASE
READ-TO-WRITE RATIO – R2W

A parte mais importante na clusterização da base de dados é a
definição da taxa de leitura por escrita (read-to-write ratio).

            R2W > 30 reads = Configuração Master-Slave
DATABASE
CONFIGURAÇÃO MASTER-MASTER

    • Utilizada para problemas de storage
    • Exige atenção nas Primary Keys (par-ímpar)
    • Não indicada para mais de 2 servidores
DATABASE
CONFIGURAÇÃO MASTER-SLAVE

UP SIDE
      • SELECT são executadas no Slave
      • INSERT, UPDATE, DELETE são executadas no Master

DOWN SIDE
   • Lag de sincronização
   • Lag de replicação
           Evite funções resolvidas em tempo de execução: NOW()
DATABASE
SHARDING: ‘particionando’ o banco de dados

UP SIDE
      • Aplicável em schemas, tables e rows
      • Distribui os dados de maneira organizada
      • Cria um modelo semântico

DOWN SIDE
   • Exige máquinas fisicamente distintas
   • Impede JOINs entre elementos em máquinas diferentes
CODIFICAÇÃO
DESIGN PATTERNS

BOAS PRÁTICAS
     Atenção aos tempos de processamento das funções nativas
     Aspas simples vs. aspas duplas
     Defina apenas as variáveis que fazem sentido


OPCode OTIMIZADO
     PECL::APC
     Xcache
     Zend Platform
CACHE
STORAGE: formas de implementação

    • INDIVIDUAL
          Fácil, mas com diferença de conteúdo por tempo de execução


    • CENTRALIZADO
          Fácil, mas Single Point of Failure


    • DISTRIBUÍDO
          Difícil, porém correto e elegante
CACHE
MEMORY: memcached

    • Data cache
    • View cache
    • PECL::memcache (3.0.2+ para redundância)
CACHE
PECL::memcache->SESSION

    • INDIVIDUAL
          Stickyness: o usuário #1 acessa sempre o server #1


    • CENTRALIZADO
          Consistente, mas Single Point of Failure


    • DISTRIBUÍDO
          Replicação e redundância
LOAD BALANCE
LOAD BALANCE
ROUND-ROBIN DNS
    • Não garante tolerância a falhas nem alta disponibilidade

SOFTWARES ESPECIALIZADOS
    • Geralmente exigem redundância de dados, aumentando o
      custo total em função de hardware

CAPACITY PLANNING
    • Precisam ser definidos a partir de dados reais e não por
      estimativas
LOAD BALANCE
STRESS TEST
     • Em ambiente de homologação e produção

MONITORAMENTO E DEFINIÇÃO DE ESTATÍSTICAS
   • Apache ab, Siege (aplicação)
   • Ganglia, Nagios (OS e serviços)
   • Firebug, YSlow (client-side)
   • Xdebug           (server-side)
CLIENT-SIDE SCRIPTING
BENCHMARKING DE BIBLIOTECAS
    • Nem sempre a mais famosa tem melhor performance

USO CORRETO DOS TIPOS DE IMAGENS
     • JPG, GIF, PNG: cada um tem sua hora e local
     • Exportação e recorte para web fazem bem
CLIENT-SIDE SCRIPTING
COMPRESSÃO DE JAVASCRIPT
CLIENT-SIDE SCRIPTING
COMPRESSÃO DE JAVASCRIPT
REFERÊNCIAS
•   PHP Architect - Volume 8, Issue 3, March 2009
    http://www.phparch.com



• SCHLOSSNAGLE, George. Advanced PHP Programming. Sams, 2004.



•   MINETTO, Elton Luís. Desenvolvendo aplicações web escaláveis
    http://www.eltonminetto.net/docs/app_web_escalaveis_xxe.pdf
Obrigado!
     @diegotf
diegotf@gmail.com

ClusterizaçãO De AplicaçõEs Php

  • 1.
    Clusterização de Aplicações PHP Diego Thomaz Flores
  • 2.
    QUEM? Analista e programadorPHP há 8 anos, já desenvolveu projetos para o Ministério do Turismo, EMBRATUR, Fundação Getúlio Vargas, Telefonica e Agência Click e Folha de São Paulo. É Gerente de Projetos na 3YZ Performance Digital, em Porto Alegre, agência especializada em marketing e posicionamento online de marcas. É responsável pela ECRAYON Tecnologia Criativa, estúdio de desenvolvimento de sistemas web- based.
  • 3.
    AGENDA • Camadas de Execução • Webserver • Database • Codificação • Cache • Load Balance • Client-side scripting
  • 4.
    Para fazer umaaplicação rodar bem numa estrutura clusterizada, ela precisa ser escrita para uma estrutura clusterizada!
  • 5.
    CAMADAS DE EXECUÇÃO •Conteúdo estático • Scripts e bibliotecas client-side • Scripts server-side • Banco de Dados • Webserver
  • 6.
    WEBSERVER DISTRIBUIÇÃO DE CONTEÚDO Diferentesdomínios para diferentes tipos de conteúdos http://www.exemplo.com (PHP, dinâmico) http://estatico.exemplo.com (imagens, CSS, HTML, documentos)
  • 7.
    WEBSERVER APACHE PREFORK APACHE WORKER • Grande consumo de memória • Menor consumo de memória • Rápido • Apache 2.0+ • Pouco escalável • Mais escalável • Até 2 CPUs • Multi-thread • 2 CPUs ou mais
  • 8.
    WEBSERVER OUTRAS OPÇÕES: servidoresmais leves • lighttpd • tux • thttpd • nginx
  • 9.
    Aplicações web geralmentenão utilizam processos que comprometam o processamento, porém geram milhares de dados e queries. Dessa forma, em aplicações bem escritas, o mais provável é que a base de dados entre em colapso primeiro.
  • 10.
    DATABASE DIMENSIONAMENTO E TIPIFICAÇÃOCORRETA DOS DADOS INT, TINYINT, BIGINT, FLOAT, DOUBLE CHAR, VARCHAR, TEXT, BLOG InnoDB vs. MyISAM InnoDB -> Foreign Keys, Constraints, Transactions MyISAM -> Data storage
  • 11.
    DATABASE READ-TO-WRITE RATIO –R2W A parte mais importante na clusterização da base de dados é a definição da taxa de leitura por escrita (read-to-write ratio). R2W > 30 reads = Configuração Master-Slave
  • 12.
    DATABASE CONFIGURAÇÃO MASTER-MASTER • Utilizada para problemas de storage • Exige atenção nas Primary Keys (par-ímpar) • Não indicada para mais de 2 servidores
  • 13.
    DATABASE CONFIGURAÇÃO MASTER-SLAVE UP SIDE • SELECT são executadas no Slave • INSERT, UPDATE, DELETE são executadas no Master DOWN SIDE • Lag de sincronização • Lag de replicação Evite funções resolvidas em tempo de execução: NOW()
  • 14.
    DATABASE SHARDING: ‘particionando’ obanco de dados UP SIDE • Aplicável em schemas, tables e rows • Distribui os dados de maneira organizada • Cria um modelo semântico DOWN SIDE • Exige máquinas fisicamente distintas • Impede JOINs entre elementos em máquinas diferentes
  • 15.
    CODIFICAÇÃO DESIGN PATTERNS BOAS PRÁTICAS Atenção aos tempos de processamento das funções nativas Aspas simples vs. aspas duplas Defina apenas as variáveis que fazem sentido OPCode OTIMIZADO PECL::APC Xcache Zend Platform
  • 16.
    CACHE STORAGE: formas deimplementação • INDIVIDUAL Fácil, mas com diferença de conteúdo por tempo de execução • CENTRALIZADO Fácil, mas Single Point of Failure • DISTRIBUÍDO Difícil, porém correto e elegante
  • 17.
    CACHE MEMORY: memcached • Data cache • View cache • PECL::memcache (3.0.2+ para redundância)
  • 18.
    CACHE PECL::memcache->SESSION • INDIVIDUAL Stickyness: o usuário #1 acessa sempre o server #1 • CENTRALIZADO Consistente, mas Single Point of Failure • DISTRIBUÍDO Replicação e redundância
  • 19.
  • 20.
    LOAD BALANCE ROUND-ROBIN DNS • Não garante tolerância a falhas nem alta disponibilidade SOFTWARES ESPECIALIZADOS • Geralmente exigem redundância de dados, aumentando o custo total em função de hardware CAPACITY PLANNING • Precisam ser definidos a partir de dados reais e não por estimativas
  • 21.
    LOAD BALANCE STRESS TEST • Em ambiente de homologação e produção MONITORAMENTO E DEFINIÇÃO DE ESTATÍSTICAS • Apache ab, Siege (aplicação) • Ganglia, Nagios (OS e serviços) • Firebug, YSlow (client-side) • Xdebug (server-side)
  • 22.
    CLIENT-SIDE SCRIPTING BENCHMARKING DEBIBLIOTECAS • Nem sempre a mais famosa tem melhor performance USO CORRETO DOS TIPOS DE IMAGENS • JPG, GIF, PNG: cada um tem sua hora e local • Exportação e recorte para web fazem bem
  • 23.
  • 24.
  • 25.
    REFERÊNCIAS • PHP Architect - Volume 8, Issue 3, March 2009 http://www.phparch.com • SCHLOSSNAGLE, George. Advanced PHP Programming. Sams, 2004. • MINETTO, Elton Luís. Desenvolvendo aplicações web escaláveis http://www.eltonminetto.net/docs/app_web_escalaveis_xxe.pdf
  • 26.
    Obrigado! @diegotf diegotf@gmail.com