Natal é legal para trocar presentes, unir família e tudo mais, mas isso dura algumas horas, nas demais ficamos sem ter o que fazer, até mesmo porque o comércio não abre. Com isso, resolvi fazer alguns testes nos principais frameworks PHP que estão no mercado: CakePHP, Code Igniter, Symfony, Yii e Zend Framework.

Todos os benchmarks que eu vejo pela internet são de um simples hello world, que às vezes não utilizam o framework como indicado e acaba desvirtuando um pouco. Além disso, muitos testam somente a versão estável, deixando pra lá algumas versões mais “quentes”, como no caso do CakePHP 1.2. Então resolvi mudar! Fiz um teste com o famoso Hello World, e outros dois: um acessando o banco de dados e lendo 10 registros e o mesmo código lendo 1000 registros. Assim, aproxima um pouco da realidade do desenvolvimento, pois não desenvolvemos Hello Worlds, mas sim acesso a banco, uso de MVC (completo e não como os exemplos que não há view!). Não testei as funcionalidades em si de cada framework como cache, ACL, componentes, etc, detive-me ao básico, acessar o banco e mostrar um dos campos.

Bem, vamos começar falando da máquina de testes. Estava rodando num Debian Etch, com processador Intel Xeon 2.66GHz, 256MB de RAM. Esta máquina é um servidor de produção que é vendido pela VirtuaServer. Ou seja, tentei fazer o teste num servidor que usamos na prática e não numa máquina local de qualquer desenvolvedor. Nesta máquina a versão do Apache é a 2.2.3, PHP 5.2.0 e MySQL 5.0.32. Nenhuma extensão de cache/performance (APC, Memcache, etc) está habilitada.

O desenvolvimento da aplicação eu fiz me baseando na documentação de cada framework e não a partir de exemplos prontos, pois queria fazer seguindo a lógica dos desenvolvedores de cada framework. Tentei deixar o mais próximo do modo de produção (desabilitando debugs, etc).

Vamos aos resultados, começando pelo famoso Hello World:

O eixo Y representa o número de requisições completadas após 30 segundos de testes. Usei a ferramenta “ab” para fazer os testes (parâmetros: -t 30 -c 10 ou -c 100. Isso significa que testei cada framework por 30 segundos, com 10 ou 100 requisições em paralelo).

Como podem ver, Yii e CodeIgniter apresentaram excelentes resultados, enquanto os demais ficaram próximos. Alguns poderiam dizer  que o CakePHP apresenta resultados inferiores por manter suporte ao PHP4, o que limita algumas coisas, mas lembro que o CodeIgniter também suporta o PHP4 e apresentou resultados surpreendentes.

PS: Fiz as aplicações antes de iniciar todos os testes, ou seja, a parte de banco de dados já estava configurada até para fazer o Hello World, então caberia a aplicação conectar/carregar “drivers” ou não…

Ok, agora vamos aos resultados dos testes dos frameworks acessando a base de dados e mostrando 10 registros:

Novamente Yii e CodeIgniter se sobressaindo… Porém, vejam que o CakePHP estável (1.1) obteve melhores resultados que o CakePHP 1.2 e mais, o CakePHP 1.2 obteve o pior resultados dos pesquisados.

Outra coisa interessante que podemos notar é que o CodeIgniter tem uma performance melhor com mais requisições em paralelo, sendo mais interessante para sites de grande porte, como portais que tem bastante acesso.

E agora o último teste: acesso ao banco com 1000 registros. A idéia deste teste é tentar visualizar se o framework tem um overhead grande por causa de registros ou por causa da pesquisa. Se pensarmos, a pesquisa é a mesma, a quantidade de registros retornados é que mudará, então é neste ponto que vamos notar as diferenças.

CodeIgniter novamente se destacando e ainda deixando o Yii mais distante que nos demais testes. Nota-se também que todos têm um overhead grande sobre os registros retornados no banco, pois diminuíram muito sua performance. O CakePHP 1.2 reduziu pouco, o que é interessante.

Vale ressaltar que o teste com 1000 registros não é tão usado na prática, pois uma página com 1000 registros pro usuário ler é um tanto quanto chato. Normalmente nestes casos há paginação. Exemplos práticos que vejo disto é na geração de relatório ou gráficos, mas que são pontos isolados e não tão usuais.

Alguns comentários sobre os desenvolvimentos das aplicações de teste:

• Do CakePHP eu não posso falar nada, pois já trabalho com ele a mais de dois anos. Os demais, desconhecia quase que totalmente;
• O Zend Framework eu tive um trabalho imenso para conseguir fazer o banco de dados funcionar. Na documentação deles eles falaram várias coisas que podem ser feitas, mas não dizem a básica: aonde vão os arquivos;
• No Zend eles recomendam que as requisições que só vão retornar textos simples seja feito no controller, por exemplo, na action do controller você coloca um die ou exit. Eu acho que isso quebra o MVC e em grandes projetos fica uma salada de fruta;
• Ainda no Zend eles recomendam que os arquivos que não são de view (não teham HTML) você não feche a tag do PHP (?>), assim evita que fiquem linhas em branco no arquivo e dê os famosos erros de não conseguir escrever no header. Ok, isso é legal, mas não fechar as tags eu acho que é amadorismo. Se o cara fechou e deixou uma linha em branco, é desatenção e deve ser corrigido e não contornado.
• O Symfony eu não sei direito tudo que ele gerou, sei que eu executava alguns comandos (indicados na documentação) e ele fazia as coisas acontecerem. Não encontrei na documentação sobre a lógica e como desenvolver manualmente…
• No Symfony, também tive problema em configurar o banco de dados, pois na documentação estava errada, mas em algumas pesquisas do Google eu achei;
• O Yii parece fácil de usar. Ele tem certas similaridades com o CakePHP (exceto na performance, como foi visto);
• Code Igniter também foi tranqüilo o desenvolvimento. A estrutura de diretórios é similar a do CakePHP, facilitando um pouco.

Minhas opiniões quanto os resultados:

• CakePHP, Yii e CodeIgniter são fáceis de desenvolver, tem uma boa organização e estruturação, ficando legíveis e bons para se trabalhar em equipes diversificadas;
• A documentação do Zend e Symfony são meio obscuras para “dummies”, tendo que quebrar um pouco a cabeça para conseguir fazer coisas simples (como o acesso ao banco).  Para quem está começando, acho que isso é um tanto quanto chato e desestimulante…
• Yii e CodeIgniter parecem ter bom desempenho na prática, porém desconheço dos recursos e de como é a forma de desenvolvimento. Temos que ver se eles não são muito amarrados aos recursos internos e não dão suporte a integração com outras aplicações/componentes.  Entretanto, se eu fosse começar um desenvolvimento hoje, estudaria um pouco mais esses dois;
• Yii é focado para web 2.0 e trabalha com jQuery (que é a onda do momento em JavaScript). Interessante… Acho que se ele incorporar algumas funcionalidades mais comerciais (testes automatizados, etc) ele terá futuro promissor e não será um fogo de palha;
• O CakePHP ainda parece o mais “potente” do mercado e tem uma boa visão comercial. Enquanto que a maioria se preocupa em fazer site “legal”, o CakePHP dá essa possibilidade e ao mesmo tempo oferece um suporte a desenvolvimento para empresas, com facilidades para desenvolvimento utilizando métodos ágeis, testes automatizados, etc.

Bem, acho que é isso. Não vou largar do CakePHP, mas não custa dar uma estudada mais a fundo nos outros.

Caso alguém tenha alguma sugestão de testes a fazer, comente! Pois vou deixar minha suite de testes montada para quando sair novas versões fazer a comparação.

Caso queiram ver os testes mais detalhados, podem acessar os últimos resultados dos testes. Neste site também está disponível o resultado mais detalhado de cada teste, inclusive os números.

Abraços.

Olhando alguns sites de otimização, benchmark, entre outros, vi que há algumas formas de otimizarmos os códigos sem grandes alterações, mas que podem melhorar a performance. São elas:

1) Aspas com variáveis

1.1) Aspas duplas VS aspas simples

Utilizar uma string com aspas simples é ligeiramente mais rápido que utilizar aspas duplas pelo fato da necessidade de interpretar varáveis (com aspas simples ele interpreta variáveis). Exemplo:

1
2

echo 'texto qualquer'; // Mais rápido
echo "texto qualquer"; // Mais lento

1.2) Variável em aspas dupla ou concatenando

Concatenar uma variável a uma string é muito mais rápido que colocar a variável dentro de uma string com aspas duplas.

1
2

echo 'texto qualquer ' . $variavel . ' outro texto'; // Quase duas vezes mais rápido
echo "texto qualquer $variavel outro texto"; // Bem mais lento

2) echo VS print

Utilizar a função echo é mais rápida que a função print, pois não retorna nenhum valor. A função print informa se houve mensagem de erro. O uso de print é recomendado só em casos que há necessidade de retorno (o que são poucos na prática). Além disso, é recomendável a utilização vários parâmetros no echo ao invés de concatenar strings. É opcional o uso de parâmetros nestes comandos, sendo o ideal não utilizar. Exemplo:

1
2
3

echo 'texto qualquer ' . $variavel . ' outro texto';
print 'texto qualquer ' . $variavel . ' outro texto'; // Mais lento que caso anterior
echo 'texto qualquer ', $variavel, ' outro texto'; // Note as vírgulas. Este caso é mais rápido que os anteriores

3) Variáveis

3.1) Nomes

Definir variáveis com nomes menores é consideravelmente mais rápido que nome maiores. Exemplo:

1
2

$a = 'texto';
$asdhaisuhniduahsduiash = 'a'; // Mais lento que anteiror, consideravelmente

3.2) Atribuições

Em atribuições, várias atribuições são mais rápidas que em atribuições unificadas. Exemplo:

1
2

$a=$b=0; // Mais lento
$a=0; $b=0; // Mais rápido

Usar os operadores +=, -=, /=, *= e .= também aumentam a performance. Exemplo:

1
2
3
4
5
6
7

$var = 'abc';
 
// Mais lento
$var = $var . 'def';
 
// Mais rápido
$var .= 'def';

3.3) [Pré/Pós]-incremento

Preferir o uso de pré-incremento (++$i) ao invés de pós-incremento ($i++), pois aquelas consumem um opcode a menos, visto que o segundo caso o PHP cria uma variável temporária para atribuir o valor e no primeiro caso não. PS: Isto vale apenas para PHP! Nas outras linguagens isto não se aplica.

4) Estruturas condicionais

4.1) if VS switch

Estruturas com if e vários elseif são mais rápidas que a estrutura switch. Exemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// Mais rápido
if ($a == 1) {
  echo 1;
} elseif ($a == 2) {
  echo 2;
} else {
  echo 3;
}
 
// Mais lento
switch ($a) {
  case 1:
    echo 1;
    break;
  case 2:
    echo 2;
    break;
  default:
    echo 3;
}

4.2) Operador ternário VS if

Operadores ternários são significativamente mais lentos que if’s. Exemplo:

1
2
3
4
5
6
7
8
9

// Mais lento
echo $a == 1 ? 1 : 2;
 
// Mais rápido
if ($a == 1) {
  echo 1;
} else {
  echo 2;
}

4.3) Operadores de igualdade

Operadores de igualdade com comparação de tipos (===) são consideravelmente mais rápidos que apenas operadores de igualdade (==). Exemplo:

1
2

if ($a == 'a') { // Mais lento
if ($a === 'a') { // Mais rápido

5) Arrays

5.1) Definição

Definir um array pelos índices é consideravelmente mais rápido que usar o método array(…). Exemplo:

1
2

$a = array('a', 'b'); // Mais lento
$a[0] = 'a'; $a[1] = 'b'; // Mais rápido

5.2) Leitura

Verificar a existência de um elemento no array é mais rápido que procurá-lo. Exemplo:

1
2

array_key_exists('texto', $arr); // Mais lento
isset($arr['texto']); // Mais rápido

PS: Se o valor do campo pode ser null, isset irá retornar false neste caso. Portanto, tome cuidado com isto.

6) Arquivos

Usar a função file_get_contents() é ligeiramente mais rápida que utilizar a função file(), porém é mais lenta que utilizar fopen() com fread(). Exemplo:

1
2
3
4
5
6
7
8
9
10

// Mais lento
$arquivo = file('arquivo.txt'); // Retorna array
 
// Pouco mais rápido que anterior
$arquivo = file_get_contents('arquivo.txt'); // Retorna string
 
// Mais rápido, significativamente
$f = fopen('arquivo.txt', 'r');
$arquivo = fread($f, filesize('arquivo.txt'));
fclose($f);

7) Buscas e validações

7.1) Substring

Ao buscar substrings, é preferível usar, na ordem, strpos(), depois preg_match() e por último ereg(). A strpos, quando é possível de ser utilizada, tem uma eficiência muito superior as demais.

7.2) Números

Caso necessite verificar se um texto ou variável contém apenas números, é preferivel utilizar a função ctype_digit($var) ao invés de preg_match(‘/[0-9]*/’, $var).

8 ) Outras otimizações

8.1) Funções de controle de saída

Uso de Usar o método ob_start() reduz de 5 a 15% o tempo de execução.

8.2) Evitando repetição de funções

Definir uma variável com um valor que vai ser usado diversas vezes aumenta a performance consideravalmente. Exemplo:

1
2

for ($i=0, $max=count($arr); $i<$max; $i++) { // Mais rápido
for ($i=0; $i<count($arr); $i++) { // Mais lento

8.3) Processamento não necessário

Blocos de textos fixos é preferível que seja impresso fora do PHP, por exemplo:

1
2

<?php echo $var; ?>
Texto adicional grande

É preferível do que:

1

<?php echo $var . 'Texto adicional grande'; ?>

8.4) Evitar o uso de funções aliases e automágicas

Funções aliases são as funções que significam a mesma coisa que outras. Por exemplo, sizeof é sinônimo (alias) de count. Veja a lista completa de funções aliases aqui.

Funções automágicas são aquelas definidas pelo PHP: __get, __set, __autoload, __call, __sleep, …

8.5) Evitar uso de funções abrangentes

Preferir a função empty() ao invés de count(), assim como isset($var{X}) ao invés de strlen($var) < X.

8.6) Declare os métodos estáticos

Definir os métodos estáticos com a palavra static deixa seu código até 4 vezes mais rápido que o não declarado como estático. Exemplo:

1
2
3
4
5
6
7

class XXX {
  public function a() { return 1; }
  public static fuction b() { return 1; }
}
 
XXX::a(); // Mais lento
XXX::b(); // Até 4 vezes mais rápido

8.7) Evitar o operador @

Ao invés de usar o operador @, desativar a exibição de erros. Exemplo:

1
2
3
4
5
6
7

// Mais lento
@acao();
 
// Mais rápido
$old = ini_set('error_reporting', 0);
acao();
ini_set('error_reporting', $old);

9) Extra-código

Se você tem acesso ao servidor web, é recomendavel a utilização de otimizadores e/ou cachers, como o Zend Optimizer, APC, eAccelerator, memcache, etc.

Outra alternativa que pode ser usada em conjunto, é usar o callback ‘ob_gzhandler‘ na função ob_start() OU ativar a configuração zlib.output_compression no php.ini. Isso faz com que depois de gerado o código HTML, ele seja compactado e enviado para o cliente, reduzindo a quantidade de tráfego na rede.

Fontes de referência:
https://trac.cakephp.org/ticket/2764
http://phplens.com/lens/php-book/optimizing-debugging-php.php
http://benchmark.nophia.de/benchmarks.html
http://www.estvideo.com/dew/pages/phpbench/
http://ilia.ws/archives/12-PHP-Optimization-Tricks.html
http://www.vulgarisation-informatique.com/optimiser-php.php
http://www.moskalyuk.com/blog/php-optimization-tips/1272
http://www.ilia.ws/files/zend_performance.pdf
http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40