Análise de performance
Me perguntaram como realmente se pode medir o desempenho de uma aplicação PHP, que tipo de classe ou ferramenta eu utilizava para fazer isso, foi então que uma pessoa me mostrou um artigo encontrado em um site respeitável na internet: Benchmarking de Aplicações PHP.
Eu não canso de ficar “de cabelo em pé” com as coisas que eu leio, principalmente na internet. Uma coisa que devemos aprender é a questionar as coisas que lemos, a internet é de domínio público. Eu posso – por exemplo – escrever um artigo sobre como fazer inseminação artificial! Seria tão ruim quanto o artigo que eu citei?! Difícil…
Vamos aos fatos. Nosso mundo é o mundo do desenvolvimento! Pro inferno com a fábrica da Coca-Cola, de Dadinhos de Amendoim e de Muppy. Quase nada que é válido pra eles é válido para o “nosso mundo”, por que insistir em querer replicar coisas que funcionam na administração de empresas em desenvolvimento de software? A resposta é simples: é muito mais fácil repetir do que pensar! Vamos analisar todos os erros do artigo, e ver como realmente medir a performance de uma aplicação.
Profiling x Benchmark
O ato de medir a performance de uma aplicação é conhecido como profiling, já benchmark é utilizado para medir a performance relativa da aplicação. benchmark é utilizado para medir o desempenho de uma aplicação em diferentes ambientes, fazem isso através de testes genéricos pré-definidos e os dados que resultam dos testes não dizem nada a respeito da aplicação, eles só são úteis se você possui outros resultados para usar de base de comparação.
Já o resultado de um profiling é absoluto. Através deste resultado você sabe em que parte do seu código estão os gargalos e os possíveis gargalos futuros. Quando se está analisando problemas de performance, o profiling é a base de todas as ações que você vai tomar enquanto que o benchmak existe para resolver problemas mais específicos.
No artigo o autor não deixa isso explícito e é extremamente fácil confundir benchmark e profiling. Medir um algoritmo contra outro (como ele fez) é benchmark, medir a performance da aplicação para saber onde ela demora mais é profiling!
Regra Número um de Análise de Performance
Agora sim as coisas ficam um pouco parecidas com o mundo real: como um cientista, no momento de analisar qualquer coisa, você não assume nada. Nada! Esse é o primeiro erro que você pode cometer e todo mundo comete. Para assumir qualquer postura em relação a algo, você precisa ter argumentos. Que argumento é mais convincente do que o resultado de um teste?!
Ferramentas de Benchmark
Quantos de nós usamos o Apache Httpd?! Praticamente todos! Pois então, o Apache Httpd vêm com uma ferramenta imbutida de benchmark muito boa, o “ab” ou “Apache Benchmark”. Com ela você consegue executar testes de chamada a uma determinada URL especificando o número de requisições que você deseja simular, o número de requisições simultâneas e depois comparar os dados. Eis os dados de comparação entre algumas ferramentas de cache em PHP.
| Sem Zend Optimizer | Com Zend Optimizer | |
|---|---|---|
| PHP Raw (Puro) | 59 | 70 |
| APC | 102 | - |
| eAccelerator | 99 | 125 |
| xCache | 109 | 125 |
Usar o “ab” é bem trivial, um simples “ab –help” é autoexplicativo e você não terá dificuldades em examinar os resultados.
Ferramentas de Profiling
Existe um formato bem conhecido de resultado de profiling chamado “CacheGrind”. É bem comum que ferramentas de profling (independente da linguagem) gerem um resultado em formato CacheGrind, o que aos olhos humanos é um terror, mas que com um programa de leitura fica muito melhor.
Portanto temos duas etapas: gerar um arquivo CacheGrind e analisá-lo. Gerar é fácil, você pode usar o xDebug para fazer isso. O Xdebug, se configurado para, irá gerar um arquivo CacheGrind sempre que uma página for executada. Se nunca usou o xDebug aconselho começar a usar, ele ajuda muito no desenvolvimento além de ser uma ótima ferramenta de profiling.
Para analisar o arquivo gerado temos diversas opcões para diferentes sistemas operacionais. A que eu mais gosto? Webgrind! Você instala ele e pronto. Nada de ficar acostumando com interface que depende do S.O. nem sentir falta de alguma funcionalidade! O WebGrind é bom o suficiente pra substituir qualquer ferramenta de análise CacheGrind desde que o arquivo de análise não seja muito grande. “Mas o que eu posso ver?” deve estar se perguntando.
Através do CacheGrind podemos saber quantas vezes determinada função, arquivo ou método foi executado; quando ele foi executado e quanto tempo demorou cada execução. Podemos ver isso em diversos níveis e em diversas ordens. Isso facilita a análise de gargalos na sua aplicação e direciona seu esforço nesses gargalos e não em suposições.
Performace x Manutenção de Código
Isso é algo que gera controvérsia, mas é muito simples. Tudo o que vimos neste post está relacionado a performance. Benchmark e profilling servem de ferramentas para ajudar a melhorar a performance de sua aplicação, elas por si só não fazem nada. Mas sem elas, você provavelmente não fará nada muito útil nessa área também.
Tenha como prioridade a manutenção de seus códigos! Vamos repetir isso mais uma vez: tenha como prioridade a manutenção dos seus códigos. Esqueça a performace de início. Peformance em último caso se resolve com hardware, manutenção não tem preço que pague nem reza que resolva.
O artigo cita, por exemplo. Trocar objetos por array torna uma aplicação mais rápida? Torna. A pergunta pertinente que deveria ser feita é: a que custo?
Você não vai precisar deixar de usar objetos em sua aplicação, o benefício é mínimo em termos de performance pra perda que você tem na manutenção do código. Dificilmente para qualquer um de nós essa troca chegue a trazer algum benefício! Por esse motivo eu critiquei tanto o artigo no início desse post. O autor foi infeliz na comparação e na conclusão.
Chega de usar PHP como uma linguagem qualquer. Ela evoluiu a muito tempo! Se você se considera um programador, evolua junto com ela! Sem mais “echo” para debug, sem mais “microtime()” para medir desempenho! Estudem, testem, pratiquem, cheguem às suas próprias conclusões!
Conclusões
Não darei nenhuma conclusão aqui, já os incitei o suficiente. Testem o que foi mostrado nesse post em suas aplicações ou seus blogs e cheguem a suas própria conclusões. Uma coisa que não citei no decorrer do post, mas acho importante, é que não existe como chegar a uma conclusão a partir de um único teste. Tenha seu “rol” de dados e a partir dele obtenha suas conclusões.
Eu fui bem duro nas críticas ao artigo citado por um motivo. Se o intuito é ensinar alguma coisa, se preocupe com as coisas que você passa. Pessoas lerão e usarão aquilo em seu dia a dia. Respeito muito as pessoas que passam o conhecimento adiante, mas isso deve ser feito com cuidado. Sugerir indiretamente ao público leitor que arrays são mais rápidos que objetos mostrando uma diferença numérica em um caso hipotético de forma isolada é prejudicial, a impressão que se tem ao final do artigo é de que não devemos usar objetos pois eles irão deixar nossas aplicações lentas, quando provavelmente (pra não dizer certamente) os objetos nunca serão os culpados pela lentidão da sua aplicação.
