Sites baseados em Kohana otimização para velocidade e escalabilidade

Question

Um site que eu construí com Kohana foi batido com uma enorme quantidade de tráfego de ontem, causando-me a tomar um passo para trás e avaliar alguns dos design. Estou curioso para saber quais são algumas técnicas padrão para otimizar aplicações baseadas em Kohana?

Estou interessado em aferição também. Preciso Benchmark::start() configuração e Benchmark::stop() para cada método-controlador, a fim de ver os tempos de execução para todas as páginas, ou eu sou capaz de aplicar o benchmarking globalmente e rapidamente?

Eu vou estar usando o Cache-biblioteca de mais tempo para vir, mas estou aberto a mais sugestões como eu tenho certeza que há muito que eu possa fazer que eu não sou simplesmente desconhece no momento.

Answer 1

O que vou dizer nesta resposta não é específico para Kohana e, provavelmente, pode ser aplicado a muitos projetos PHP.

Aqui estão alguns pontos que vêm à minha mente quando se fala de desempenho, escalabilidade, PHP, ...
Eu usei muitos desses idéias ao trabalhar em vários projetos - e ajudaram; para que eles provavelmente poderia ajudar aqui também.

Primeiro de tudo, quando se trata de performances, há muitos aspectos / questões que estão a considerar :

• configuração do servidor (ambos Apache, PHP, MySQL, outros daemons possíveis, e do sistema) ; que você pode obter mais ajuda sobre isso em ServerFault , suponho,
• código PHP,
• consultas de banco de dados,
• Usar ou não o seu servidor web?
• Você pode usar qualquer tipo de mecanismo de cache? Ou você precisa sempre mais que dados atualizados no site?

Usando um proxy reverso

A primeira coisa que poderia ser realmente útil é usar um proxy reverso , como verniz , na frente de seu servidor web: deixá-lo cache de tantas coisas quanto possível , portanto, apenas os pedidos que realmente precisam de cálculos PHP / MySQL (e , é claro, alguns outros pedidos, quando eles não estão no cache do proxy) torná-lo para o Apache / PHP / MySQL.

• Em primeiro lugar, o seu CSS / JavaScript / Images - bem, tudo o que é estático - , provavelmente, não precisa ser sempre servido pelo Apache
  • Assim, você pode ter o cache de proxy reverso todos aqueles.
  • Servindo os arquivos estáticos não é grande coisa para o Apache, mas a menos que tem de trabalho para aqueles, mais ele será capaz de fazer com PHP.
  • Lembre-se:. Apache só pode servidor um finito, limitado, número de pedidos de uma só vez
• Em seguida, temos o proxy reverso servir como muitos PHP-páginas quanto possível de cache: há provavelmente algumas páginas que não mudam, que muitas vezes , e pode ser servido a partir do cache. Em vez de usar alguns de cache baseado em PHP, por que não deixar que outra, mais leve, servidor servir aqueles (e buscá-los a partir do servidor PHP ao longo do tempo, então eles estão sempre quase até à data) ?
  • Por exemplo, se você tem alguns feeds RSS (Nós geralmente tendem a esquecer aqueles, quando estiver tentando otimizar para performances) que são solicitados muitas vezes , tê-los em cache para um par de minutos pode salvar centenas / milhares de solicitação para Apache + PHP + MySQL!
  • O mesmo para as páginas mais visitadas do seu site, se não mudar, pelo menos, um par de minutos (exemplo:? Homepage) , então, não há necessidade de desperdiçar CPU re-geração -los cada vez que um usuário solicita-los.
• Talvez haja uma diferença entre páginas servidas para usuários anônimos (a mesma página para todos os usuários anônimos) e páginas servidas para usuários identificados ( "Olá Sr. X, você tem novas mensagens" , por exemplo) ?
  • Se assim for, provavelmente você pode configurar o proxy reverso para armazenar em cache da página que é servido para usuários anônimos (com base em um cookie, como o cookie de sessão, tipicamente)
  • Vai significar que Apache + PHP tem menos a lidar com:. Usuários identificadas apenas - o que poderia ser apenas uma pequena parte dos seus utilizadores

Sobre usando um reverse-proxy como cache de , para uma aplicação PHP, você pode, por exemplo, dar uma olhada em resultados de benchmark Mostrar 400% -700% aumento da capacidade do servidor com APC e Squid cache .
(Sim, eles estão usando Squid, e eu estava falando de verniz - que é apenas uma outra possibilidade ^^ Varnish being mais recente, mas o mais dedicado a caching)

Se você fizer isso bem o suficiente, e conseguem parar re-gerando muitas páginas uma e outra vez, talvez você não vai mesmo ter de otimizar qualquer um dos seu código ;-)
Pelo menos, talvez não em qualquer tipo de pressa ... E é sempre melhor realizar otimizações quando você não está sob demasiada presure ...

Como nota: você está dizendo no OP:

Um site que eu construí com Kohana foi batido com uma enorme quantidade de tráfego de ontem,

Este é o tipo de situação súbita onde um reverse-proxy pode literalmente salvar o dia , se o site pode lidar com a não ser atualizados a cada segundo:

• instalá-lo, configurá-lo, deixá-lo sempre - todos os dias normais - executar:
  • configurá-lo para não manter páginas PHP em cache; ou apenas por uma curta duração; Desta forma, você sempre tem-se a dados de data exibida
• E, no dia em que tomar um slashdot ou efeito digg:
  • Configurar o proxy reverso para manter páginas PHP em cache; ou por um longo período de tempo; talvez suas páginas não será atualizado a cada segundo, mas permitirá que o seu site para sobreviver ao efeito digg!

Sobre isso, Como posso detectar e sobreviver estar “slashdotted”? pode ser uma leitura interessante.

No lado do PHP de coisas:

Primeiro de tudo: você está usando uma versão recente de PHP ? Há regularmente melhorias na velocidade, com novas versões ;-)
Por exemplo, dê uma olhada em referência de Ramos PHP 3.0 a 5.3-CVS .

Note que o desempenho é bastante uma boa razão para usar o PHP 5.3 ( Eu fiz alguns benchmarks (em francês) , e os resultados são ótimos) ...
Outro ser uma boa razão bastante, é claro, que o PHP 5.2 atingiu o fim da vida, e não é mais mantido!

Você está usando qualquer opcode cache?

• Estou pensando em APC - Alternative PHP Cache , por exemplo, ( pecl , manual do ) , que é a solução que eu' vi o mais utilizado - e que é usado em todos os servidores em que eu trabalhei.
  • Veja também: Slides APC Facebook ,
  • ou Os resultados de benchmark revelam 400% -700% aumento da capacidade do servidor com APC e Squid cache .
• Ela pode realmente diminuir o CPU-carga de um servidor muito, em alguns casos, (eu vi CPU-load em alguns servidores ir de 80% a 40%, apenas através da instalação de APC e ativá-lo do código de operação funcionalidade -cache!)
• Basicamente, a execução de um script PHP vai em duas etapas:
  • Compilação do código-fonte PHP para opcodes (espécie de um equivalente de bytecode de Java)
  • execução desses opcodes
  • APC mantém os na memória, para que haja menos trabalho a ser feito cada vez que um PHP script / arquivo é executado:. Única buscar os opcodes de RAM, e executá-los
• Você pode precisar dar uma olhada em APC é opções de configuração , a propósito
  • existem muito poucos daqueles, e alguns podem ter um grande impacto em ambos / CPU-load speed / facilidade de uso para você
  • Por exemplo, a desativação [apc.stat](https://php.net/manual/en/apc.configuration.php#ini.apc.stat) pode ser bom para o sistema de carga; mas isso significa que as modificações feitas nos arquivos PHP não será ter em conta a menos que você liberar todo opcode-cache; sobre isso, para mais detalhes, ver, por exemplo Para stat () Ou Para não stat ()?

Usando cache para dados

Tanto quanto possível, é melhor evitar fazer a mesma coisa uma e outra vez .

A principal coisa que eu estou pensando é, naturalmente, consultas SQL: muitas de suas páginas, provavelmente, fazer as mesmas perguntas, e os resultados de algumas dessas é provavelmente quase sempre o mesmo ... o que significa lotes de < em> "inúteis" consultas feitas ao banco de dados, que tem de gastar tempo servindo os mesmos dados repetidamente.
Claro, isso é verdade para outras coisas, como chamadas de Web Services, buscar informações de outros sites, cálculos pesados, ...

Pode ser muito interessante para você identificar:

• Quais as consultas são executadas muitas vezes, sempre retornando os mesmos dados
• Que outros (pesado) cálculos são feitos muito tempo, sempre retornando o mesmo resultado

E armazenar esses dados / resulta em algum tipo de cache, de modo que eles são mais fáceis de obter - mais rápido - e você não tem que ir para o seu servidor SQL para "nada".

Grandes mecanismos de cache são, por exemplo:

• APC : além do código de operação-cache que eu falei anteriormente, que lhe permite armazenar dados na memória,
• e / ou memcached ( ver também ) , que é muito útil se você literalmente tem lotes de dados e / ou são usando vários servidores , como ele é distribuído.
• é claro, você pode pensar sobre arquivos; e provavelmente muitas outras ideias.

Eu tenho certeza que o seu quadro vem com algumas coisas cache-relacionados; você provavelmente já sabe que, como você disse "Eu vou estar usando o Cache-biblioteca mais no futuro" no OP; -)

Profiling

Agora, uma coisa agradável a fazer seria usar o Xdebug extensão perfil de seu aplicativo :., muitas vezes, permite encontrar um par de fracas-spots muito facilmente - pelo menos, se houver qualquer função que leva muito tempo

configurado corretamente , ele irá gerar perfis de arquivos que podem ser analisados com algumas ferramentas gráficas, tais como:

• KCachegrind : o meu favorito, mas só funciona no Linux / KDE
• Wincachegrind para janelas; ele faz um pouco menos coisas do que o KCachegrind, infelizmente -. ele não exibir callgraphs, tipicamente
• Webgrind que é executado em um servidor web PHP, assim que funciona em qualquer lugar - -., mas provavelmente tem menos recursos

Por exemplo, aqui estão algumas capturas de tela do KCachegrind:

<sub>(fonte: pascal-martin.fr )

(fonte: pascal-martin.fr )</sub>

(BTW, o callgraph apresentado na segunda imagem é tipicamente algo que nenhum WinCacheGrind nem Webgrind pode fazer, se bem me lembro ^^)

(Graças @Mikushi pelo comentário) Outra possibilidade que eu não tenha usado muito é o da xhprof extensão:. ele também ajuda com perfis, pode gerar callgraphs - mas é mais leve que Xdebug, o que significa que você deve ser capaz de instalá-lo em um servidor de produção

Você deve ser capaz de usá-lo alonside XHGui , que será ajuda para a visualização de dados.

No lado do SQL das coisas:

Agora que já falei um pouco sobre PHP, nota que é mais do que possível que o gargalo não é o lado do PHP de coisas , mas o banco de dados ...

Pelo menos duas ou três coisas, aqui:

• Você deve determinar:
  • Quais são as perguntas mais frequentes seu aplicativo está fazendo
  • Se aqueles são otimizados (usando os índices direita , principalmente?) , usando o EXPLAIN instrução, se você estiver usando MySQL
    • Veja também: Otimizando SELECT e outras declarações
    • Você pode, por exemplo, ativar log_slow_queries para obter uma lista dos pedidos que take " muito " tempo, e comece a sua otimização por aqueles.
  • se você poderia armazenar em cache algumas dessas consultas (ver o que eu disse anteriormente)
• O seu MySQL bem configurado? Eu não sei muito sobre isso, mas existem algumas opções de configuração que podem ter algum impacto.
  • Otimizando o Servidor MySQL pode dar-lhe algumas informações interessantes sobre isso.

Ainda assim, os dois a maioria das coisas importantes são:

• Não vá para o DB se você não precisa: Cache tanto quanto você pode
!
• Quando você tem que ir para a DB, use consultas eficientes: índices de uso; e perfil!

E o que agora?

Se você ainda está lendo, o que mais poderia ser otimizado?

Bem, ainda há espaço para melhorias ... Um par de idéias orientada a arquitetura poderia ser:

• Mudar para uma arquitetura n-tier:
  • Coloque MySQL em outro servidor (2-tier: um para PHP; o outro para MySQL)
  • Usar vários servidores PHP (e carregar-balancear os usuários entre aqueles)
  • Use outro máquinas para arquivos estáticos, com um servidor web mais leve, como:
    • lighttpd
    • nginx -. Este está se tornando mais e mais popular, btw
  • Use vários servidores para MySQL, vários servidores para PHP, e vários reversa proxies em frente daqueles
  • É claro: instalar memcached daemons em qualquer servidor tem qualquer quantidade de RAM livre, e usá-los para armazenar em cache o máximo que puder / faz sentido.
• Use algo "mais eficiente" que o Apache?
  • I ouvir mais e mais frequentemente sobre nginx , que é suposto ser grande quando se trata de sites PHP e de alto volume; Eu nunca usei isso sozinho, mas você pode encontrar alguns artigos interessantes sobre o assunto na rede;
    • , por exemplo, PHP desempenho III -. Correndo nginx
    • Veja também: PHP-FPM - FastCGI Process Manager , que é conjunto com o PHP> = 5.3.3, e faz maravilhas com nginx.

Bem, talvez algumas dessas idéias são um exagero pouco em sua situação ^^
Mas, ainda assim ... Por que não estudá-los um pouco, apenas no caso? ; -)

E sobre Kohana?

A sua pergunta inicial foi sobre a otimização de um aplicativo que usa Kohana ... Bem, eu postei alguns idéias que são verdadeiras para qualquer aplicação PHP ... que significa que são verdadeiro para Kohana demais ;-)
(Mesmo se não for específico para ele ^^)

Eu disse: cache de uso; Kohana parece apoiar algumas coisas caching (Você falou sobre isso sozinho, por isso nada de novo aqui ...)
Se existe alguma coisa que pode ser feito rapidamente, experimentá-lo; -)

Eu também disse que você não deve fazer nada que não é necessário; há algo ativado por padrão no Kohana que você não precisa?
navegar na net, parece que há pelo menos alguma coisa sobre filtragem XSS; você precisa disso?

Ainda assim, aqui está um par de links que podem ser úteis:

• Kohana Discussão Geral:? Cache
• Comunitário de Apoio: Web Site Optimization: máximo desempenho de site usando Kohana

Conclusão?

E, para concluir, um pensamento simples:

• Quanto vai custar a sua empresa a pagar-lhe 5 dias? - considerando que é uma quantidade razoável de tempo para fazer algumas grandes otimizações
• Quanto vai custar a sua empresa para comprar (paga?) um segundo servidor, e sua manutenção?
• E se você tem que escala maior?
  • Quanto vai custar para passar 10 dias? Mais? otimizar cada pedaço possível de sua aplicação?
  • E quanto por um par mais servidores?

Eu não estou dizendo que você não deve optimize: você definitivamente deve!
Mas ir para otimizações "rápidos" que você vai ter grandes recompensas em primeiro lugar: usando algum opcode cache pode ajudar você a obter entre 10 e 50 por cento de desconto CPU-carga do seu servidor ... E é preciso apenas um par de minutos para configurar ;-) por outro lado, passar 3 dias para 2 por cento ...

Oh, e, btw: antes de fazer qualquer coisa: colocar algumas coisas monitoramento no lugar , então você sabe o que melhorias foram feitas, e como!
Sem monitoramento, você não terá nenhuma idéia do efeito do que você fez ... Nem mesmo se é uma otimização real ou não!

Por exemplo, você poderia usar algo como RRDtool + < strong> cactos .
e mostrando o seu patrão alguns gráficos agradáveis ??com uma queda de CPU-carga 40% é sempre grande; -)

De qualquer forma, e para realmente CONCLude: se divertir !
(Sim, a otimização é divertido!)
(ergh, eu não acho que eu iria escrever que muito ... Espero, pelo menos, algumas partes deste são úteis ... E eu deveria lembrar esta resposta: pode ser útil algumas outras vezes ... )

Answer 2

Use XDebug e WinCacheGrind ou WebCacheGrind para perfil e analisar execução de código lento.

_{(fonte: jokke.dk )}

Answer 3

código de perfil com XDebug .

Use um monte de caching. Se as suas páginas são relativamente estática, então proxy reverso pode ser a melhor maneira de fazê-lo.

Answer 4

Kohana é fora da caixa muito, muito rápido, exceto para o uso de objetos de banco de dados. Para citar Zombor "Você pode reduzir o uso de memória, garantindo que você está usando o objeto de resultado do banco de dados em vez de matrizes de resultado." Isso faz uma diferença de desempenho HUGEE em um site que está sendo bateu. Não só usar mais memória, ele retarda a execução de scripts.

Além disso - você deve usar o cache. Eu prefiro memcache e usá-lo em meus modelos como este:

public function get($e_id)
{
    $event_data = $this->cache->get('event_get_'.$e_id.Kohana::config('config.site_domain'));

    if ($event_data === NULL)
    {
        $this->db_slave
            ->select('e_id,e_name')
            ->from('Events')
            ->where('e_id', $e_id);

        $result = $this->db_slave->get();
        $event_data = ($result->count() ==1)? $result->current() : FALSE;

        $this->cache->set('event_get_'.$e_id.Kohana::config('config.site_domain'), $event_data, NULL, 300); // 5 minutes
    }

    return $event_data;
}

Isso também irá aumentar dramaticamente o desempenho. As duas técnicas acima melhorou o desempenho sítios por 80%.

Se você deu mais algumas informações sobre onde você acha que o gargalo é, eu tenho certeza que podemos dar algumas idéias melhores.

Também confira YSlow (google) para algumas outras dicas de desempenho.

Answer 5

estritamente relacionada com Kohana (você provavelmente já ter feito isso, ou não):

No modo de produção:

1. Ativar armazenamento em cache interno (isto só irá armazenar em cache a Kohana :: resultados find_file, mas isso realmente pode ajudar muito.
2. profiler Disable

Apenas meus 2 centavos:)

Answer 6

Eu concordo totalmente com o XDebug e respostas de cache. Não olhe directamente para a camada Kohana para a otimização até que você tenha identificado os seus maiores gargalos de velocidade e escala.

XDebug irá dizer-lhe que você estava passar a maior parte do seu tempo e identificar os 'hotspots' no seu código. Manter essas informações de perfil para que você possa linha de base e melhorias de desempenho medida.

Exemplo problema e solução: Se você achar que você está construindo-se objetos caros do banco de dados de cada vez, que realmente não mudam, muitas vezes, então você pode olhar para cache-los com memcached ou outro mecanismo. Todas essas correções de desempenho levar tempo e adicionar complexidade ao seu sistema, por isso não deixe de seus gargalos antes de começar a corrigi-los.