Archive for julho \26\-02:00 2011

PHP Profiler com xdebug e webgrind

Posted on julho 26, 2011. Filed under: PHP, Tuning |

Um dos principais fatores à se levar em consideração no desenvolvimento de um software é o desempenho, principalmente se houverem muitos acessos. A maioria dos desenvolvedores acabam deixando de lado uma ánalise mais profunda do desempenho da aplicação e isso gerá insatisfação e incomodo para o usuário final. Com a utilização principalmente de frameworks MVC e programação orientada a objetos, nossas aplicações PHP ganham bastante em qualidade, facilidade em manutenção e reutilização de código, porém teremos uma redução na parte de desempenho. O objetivo de nossa ánalise aqui é poder mostrar à você como podemos fazer para identificar gargalhos nas aplicações e agir em cima desses pontos mais lentos afim de melhorar o desempenho. Para ajudar na análise vamos utilizar a combinação xdebug + webgrind.

Xdebug

Xdebug é uma extensão do PHP com a finalidade de nos ajudar a debugar mais detalhadamente nossos scripts. Iremos abordar mais especificamente o Xdebug Profiler. O profiler do xdebug é uma poderosa ferramenta de geração de dados estatísticos com a finalidade de identificar gargalos, ajudando o desenvolvedor na árdua tarefa de melhorar o desempenho de suas aplicações. Os dados são gerados em um formato de arquivo compatível com cachegrind. Portanto além do xdebug precisamos instalar um programa que nos ajude à analisar os dados gerados no formato do cachegrind. As principais opções desse tipo de software que temos são o KCacheGrind e Webgrind. Neste artigo vamos explicar como instalar e configurar o Webgrind que é uma ótima opção disponível.

Instalando xdebug no Linux Ubuntu:

Para habilitar o profiler do xdebug no PHP é bem simples. Primeiro instale a extensão do xdebug:

$ sudo apt-get install php5-xdebug

Edite o arquivo:

$ sudo vim /etc/php5/apache2/conf.d/xdebug.ini

Insira a seguinte configuração:

zend_extension=/usr/lib/php5/20090626/xdebug.so
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = /log/xdebug

A primeira linha é caminho onde esta localizado o arquivo referente à extensão xdebug.
A segunda linha habilita o profiler do xdebug que é o que nos interessa.
A terceira linha define o caminho onde os arquivos de saída do xdebug serão gerados. O PHP deve ter permissão para escrever neste diretório:

$ sudo chown www-data /log/xdebug

Reinicie o Apache:

$ sudo /etc/init.d/apache2 restart

Neste nomento o xdebug deve estar habilitado e gerando o log no diretório /log/xdebug. Para verificar se a extensão foi instalada corretamente, crie um novo arquivo php com a função phpinfo() e procure pela seção xdebug para se certificar que a extensão esta corretamente instalada.

Vamos agora à instalação do Webgrind.

Instalando WebGrind

Precisamos de um software que nos ajude a analisar os logs gerados pelo xdebug. O nosso escolhido é o webgrind. Segue abaixo os detalhes de como instalar o webgrind.

A instalação é bem simples. Basicamente é baixar o arquivo zip de instalação, descompactar ele dentro do documentroot de seu servidor web (É necessário que ele seja descompactado dentro de algum diretório que possa ser acessado através do seu domínio web):

$ cd /var/www
$ sudo wget http://webgrind.googlecode.com/files/webgrind-release-1.0.zip
$ unzip webgrind-release-1.0.zip

Configurando o Webgrind

O webgrind necessita de uma configuração inicial para poder funcionar corretamente. Edite o arquivo config.php dentro do diretório do webgrind. Configure as seguintes opções:

  • $storageDir – Caminho para diretório onde o webgrind irá armazenar arquivos cachegrind já processados. Este diretório deve ter permissão de escrita do usuário do apache/php.
  • $profileDir – Caminho para o diretório onde estão os arquivos de log gerados pelo xdebug. Por padrão o caminho utilizado é o especificado na diretiva xdebug.profiler_output_dir. Porém caso não tenha o xdebug instalado no mesmo servidor do webgrind você deverá especificar o caminho correto para essa opção.
  • $defaultTimezone  – Configure corretamente o fuso horário da sua região. No meu caso, foi definido para ‘America/Sao_Paulo’. Para ajudar à verificar corretamente o nome do fuso horário da sua região acesse o link http://php.net/manual/en/timezones.php

Exemplo arquivo config.php:

static $storageDir = '/webgrind';
static $profilerDir = '/log/xdebug';
...
static $defaultTimezone = 'America/Sao_Paulo';
...

Neste momento o webgrind já pode ser acessado:

http://localhost/webgrind

Tela Webgrind

O webgrind disponibiliza informações detalhadas à respeito das requisições realizadas em sua aplicação php, como por exemplo:

  • Se o tempo esta sendo gasto em funções internas ou em funções definidas pelo usuário.
  • Exibe de onde as funções são chamadas e quais funções elas estão chamando.
  • Gerenciar o tempo gasto exibindo no formato “Total Self Cost” e “Total Inclusive Cost”. “Inclusive Cost” é o tempo gasto dentro da função + chamadas para outras funções.

É importante utilizar o webgrind por algum tempo até se familiarizar com ele. Através dele consegui facilmente identificar pontos na aplicação que poderiam ser melhorados. Conheciumento pelo menos em nível intermediário em php é necessário.

Boa sorte!

Ler Post Completo | Make a Comment ( 1 so far )

Tuning Apache 2.x

Posted on julho 19, 2011. Filed under: Linux, Tuning |

O objetivo deste artigo é ajudar você a melhorar o desempenho do seu servidor web Apache. Da versão 1.3 para versão 2.x aconteceram diversas melhorias relacionadas ao desempenho. Porém ainda é possível melhorar ainda mais a perfomance manipulando alguns parâmetros de configuração. O Objetivo aqui é abordar os principais parâmetros de configuração que possam influenciar diretamente na perfoamance.

Hardware

O principal fator no hardware que afeta a perfomance do Apache é memória. Monitore seu servidor para que ele nunca precise utilizar memória da swap. Você pode controlar a quantidade de memória utilizada pelo servidor através do parâmetro MaxClientes como veremos mais adiante. Além disso, procure sempre ter placas de redes, discos e cpus mais rápidos possíveis.

AllowOverride

Caso você esteja utilizando a solução AllowOverride junto com .htaccess, o Apache irá tentar abrir o arquivo .htaccess em cada requisição efetuada para o servidor prejudicando a perfomance. Por exemplo, caso você utilize:

DocumentRoot /var/www
<Directory />
  AllowOverride All
</Directory>

Ao chegar uma requisição para /index.html, o Apache irá tentar abrir os arquivos /.htaccess, /var/.htaccess e /var/www/.htaccess em todas requisições recebidas. Para evitar essa sobrecarga no servidor, se possível, desabilite a opção AllowOverride:

DocumentRoot /var/www
<Directory />
  AllowOverride None
</Directory>

Procure transportar toda configuração que você tiver dentro dos arquivos .htaccess para a configuração principal do apache ou virtual host. Por exemplo, caso você tenha a configuração no arquivo /var/www/protegido/.htaccess:

Deny from all

Transportando para o virtual host na configuração do apache:

<Directory "/var/www/protegido/">
  Deny from all
</Directory>

ExtendedStatus

Caso esteja usando mod_status para monitorar os processos do apache garanta que a opção ExtendedStatus esteja Off caso contrário o apache irá realizar diversas chamadas adicionais no sistema para cada requisição recebida.

<Location /server-status>
  SetHandler server-status
  ExtendedStatus Off
  Order deny,allow
  Deny from all
  Allow from localhost ip6-localhost
</Location>

SymLinks

A opção FollowSymLinks diz ao apache para seguir todos os links simbólicos do diretório. Caso essa opção esteja Off o Apache irá executar processos extras para verificar se o diretório ou arquivo não é um link simbólico. Portanto deixe essa opção sempre habilitada quando possível:

DocumentRoot /www/htdocs
<Directory />
  Options FollowSymLinks
</Directory>

Caso necessite de uma segurança maior e queira usar a opção SymLinksIfOwnerMatch ao invés da FollowSymLinks lembre-se que téra um custo maior nesse caso, pois a opção SymLinksIfOwnerMatch fará com que o apache verifique se o usuário dono do link corresponde ao mesmo usuário dono do destino do link. Então use-a com critério. Outra opção é a configuração abaixo, que faz com que a utilização SymLinksIfOwnerMatch seja menos custosa:

DocumentRoot /www/htdocs
<Directory />
  Options FollowSymLinks
</Directory>

<Directory /www/htdocs>
  Options -FollowSymLinks +SymLinksIfOwnerMatch
</Directory>

Essa última configuração evita checagens extras no DocumentRoot.

KeepAlive

A opção KeepAlive permite que o apache trabalhe com conexões persistentes, ou seja, é possível que milhares de requisições sejam tratadas em uma mesma conexão TCP. Habilitar essa opção reduz significativamente a carga do sistema.

Segue abaixo a configuração para ser inserida no arquivo de configuração do Apache, habilitando o KeepAlive:

KeepAlive On
MaxKeepAliveRequests 1000
KeepAliveTimeout 3

A diretiva MaxKeepAliveRequests determina o número máximo de requisições permitidas para uma conexão persistente. Defina um valor alto para uma melhor perfomance.

A diretiva KeepAliveTimeout determina o número de segundos que o Apache irá aguardar por uma subsequente requisição antes de fechar a conexão persistente. Defina para um valor pequeno. Valores altos poderão prejudicar a perfomance. Quanto maior o valor, maior o número de processos ficarão ocupados esperando por requisições enquanto não chega no timeout especificado.

MaxClients

A opção MaxClients determina o número limite de conexões simultâneas tratadas pelo Apache. Caso a conexão não possa ser tratada, pois chegou no limite máximo de conexões simultâneas, a conexão será colocada em uma fila. Essa diretiva influencia diretamente na performance do servidor. Caso seja definida um número pequeno, poderá estar consumindo pouco recurso do servidor, deixando-o ocisoso. Setar para um valor muito alto, poderá consumir 100% dos recursos, principalmente memória. Uma regra para calcular um número ideal para essa diretiva, é determinar a média do tamanho de um processo do apache, através de um comando como o top, e dividir pela quantidade de memória disponível, deixando, é claro, na suas contas, uma quantidade de memória para outros processos.

Segue a equação:

MaxClients ≈ (RAM - qtde memória para outros processos)/(média do processo apache)

Para obter quantidade de memória disponível no sistema: (Verificar -/+ buffers/cache: para obter quantidade de memória livre).

# free -m

Para ajudar a calcular o tamanho médio do processo do apache, pode utilizar top, ou o comando ps. Segue o comando ps abaixo para ajudar:

# ps -ylC apache2 --sort:rss

Espeque que alguma dessas dicas possa tê-lo ajudado a tornar seu apache mais rápido. Abraço!

Ler Post Completo | Make a Comment ( None so far )

Liked it here?
Why not try sites on the blogroll...

%d blogueiros gostam disto: