Framework x Desempenho

[AlexOliveira 0]

Olá pessoal!

 

Eu programo em PHP já ha algum tempo mas só agora estou começando a utilizar framework para o desenvolvimento e isso ja esta me trazendo uma grande dúvida. Estou modelando um projeto pessoal no qual eu preciso de muita performace para que os usuários possam ter resultados rápidos. Após uma boa olhada nas minha alternativas ( PHP, JAVA, ASP ) eu acabei continuando com PHP mesmo mas e me decidir a utilizar o ZendFramework. Estou estudando o FZ apartir de um livro (ZendFramework em Ação) para implementar o meu projeto, entretanto o autor deixa claro no livro que a aplicação no framework nao sera tão rapida como o PHP puro codificado voltado para um projeto (foi o q eu entedi pelo menos), isso me colocou uma grande enterrogação: "Sera que vai valer a pena utilizar o ZF?"

 

Entendo que o zend framework e um dos melhores para PHP, está bastante consolidado nas empresas de desenvolvimento e ja consigo, apos alguns capitulos do livro, ver quantas facilidades ele trás para que o desenvolvedor faça seu trabalho de forma rapida e segura, porém e a performace??? Me parece que um framework é apenas uma biblioteca para que o desemvolvedor satisfaça com mais eficiência a necessidade da uma empresa de reaproveitamento, segurançao e etc.

 

Agora a quetao é: ja que eu nao pretendo reaproveitar o código para a construção de outra aplicação e preciso ter uma codificação voltada a solução do meu problema com o máximo de desempenho, VALE A PENA ABANDONAR O ZENDFRAMEWORK E DESEMVOLVER MINHA APLICAÇÃO UTILIZANDO O PHP PURO criando bibliotecas personalizadas que disperdisse meus recursos?????

 

E ai pessoal o que q vocês acham??

[Leozitho 81]

Na verdade não é o framework em si que causa perda de desempenho e sim a programação orientada a objetos.

 

Se você for analisar no ZendFramework, por exemplo, pra fazer a requisição de uma única página são instanciadas dezenas de classes (classes para conexão com banco de dados, controllers, models, etc), sem falar as classes que são extendidas. Já na programação procedural muitas vezes se utiliza um único arquivo de funções para armazenar funções simples e a maioria das funções nativas do PHP são utilizadas de forma direta.

 

É claro que varia bastante a perda de desempenho de framework pra framework, mas isso depende de como eles estão estruturados. O CodeIgniter, por exemplo, é muito melhor em desepenho do que o ZF, mas eu já usei esses dois frameworks e posso garantir que o ZF é muito melhor estruturado.

 

Na programação orientada a objetos se perde em desempenho mas se ganha na reutilização do código, organização, etc.

[AlexOliveira 0]

Tem razão, Leozitho.

 

Por esse lado entao eu deveria abandonar tambem a POO para alcançar o máximo que a linguagem pode me oferecer...?!

 

Sera que valera a pena?? Se o projeto der certo vou precisar dar manutenção e ai vou ter muito trabalho mas o custo será menor que o benefício?? O quanto uma aplicação estruturada e mais veloz que uma orientara??? 1% 5% 10% 50%???

 

O que vale mais a pena?

 

 

E ai pessoal o que achar??

[Bruno Augusto 417]

O maior problema nem chega a ser da Orientação a Objetos.

 

É verdade que quanto mais "quebrado" em várias classes um sistema estiver, menos velocidade ele terá, mas o vilão da história não é o conceitoe sim a forma como as classes são localizadas e instanciadas.

 

Quando trabalhando com OOP, é quase inevitável trabalhar também com algum tipo de autoloader. E ele sim é o maior vilão.

 

Mesmo que você faça um autoloader super simples, como esse abaixo, para suporte à namespaces:

 

spl_autoload_register(

   function( $class ) {

       require_once str_replace( DIRECTORY_SEPARATOR, '\\', $class );
   }
);

Sua aplicação será, em média, três vezes mais "lerda".

 

Existe, porém, um "truque" para se recuperar essa performance perdida. A idéia é quase a mesma dos Frameworks JavaScripts que são "compilados" num único arquivo a fim de minimizar o tempo de carregamento para o usuário final.

 

O desenvolvedor recurso continuaria com os sources "decompilados", isto é, totalmente estruturado em dezenas de diretórios, com centenas de classes, organizado e etc. Para o usuário (ou para o desenvolvedor que use as bibliotecas), é indiferente, pois seria necessário apenas um único require/include.

 

Mas tem um problema, que eu mesmo reportei como bug (e até hoje nada). Se você criar um único super arquivo, com todas classes sob um mesmo namespace, as interfaces não funcionam. Assim:

 

<?php 

namespace Test {

   class First extends Zero {}

   class Second {

       public function getMessage() {
           return 'Message from Second Class';
       }
   }

   abstract class Zero implements TestInterface {

       public function __construct() {

           // Using a second class

           $second = new Second;

           print $second -> getMessage();
       }
   }

   interface TestInterface {}  
}

?>

Executando esse código veremos um Fatal error: Class 'Test\Zero' not found...

 

Mas se removermos a declaração do implements (e sua respectiva interface, obviamente), vemos a mensagem definida (Message from Second Class)

 

Nota: O teste é feito apenas por instanciar a classe First

 

E com isso, se as interfaces deixam de funcionar, perdemos dois grandes pontos em favor da Orientação à Objetos, mesmo que um deles sejam possível de contornar (mesmo que deselegantemente): os "contratos" que as classes firmam com as interfaces e o polimorfismo.

[Leozitho 81]

Eu não acho que vale a pena abrir mão da orientação a objetos apenas por questões de desempenho.

 

Desepenho é muito importante e eu me preocupo bastante com isso, inclusive essa foi uma das razões que fez eu demorar pra largar o CI e partir para um framework mais robusto como o ZF. E também tem a questão de SEO, se sabe que quanto menor o tempo de resposta de um site maior a relevancia para os mecanismos de busca.

 

Mas para trabalhar com POO e manter um bom desempenho você deve procurar maneiras de otimizar ao máximo a sua aplicação, uma boa prática para isso é usar cache por exemplo.

[João Batista Neto 448]

Alex, a resposta é simples:

 

Sim, Framework interfere muito no desempenho já que ele é feito para atender N casos genéricos.

 

Se o desempenho é importante, procure desenvolver algo específico.

 

 

Na verdade não é o framework em si que causa perda de desempenho e sim a programação orientada a objetos.

 

????

 

Claro que é o framework que causa a perda de desempenho, o fato dele carregar soluções para N casos que, provavelmente, você jamais vai utilizar, ele é pesado e lento.

 

É como sair de viagem para 2 dias e levar consigo uma bagagem para 2 anos, você carregará coisas que não vai utilizar e, por isso, será mais lento.

 

A orientação a objetos não tem nada a ver com a perda de desempenho e posso lhe garantir que uma aplicação orientada a objetos tende a ser muito eficiente em termos de desempenho e, muitas vezes, muito mais eficiente que uma aplicação procedural não planejada.

 

O paradigma, nesse caso, não é a causa da perda de desempenho, a causa é:

 

1. Muito peso.

2. Falta de planejamento.

 

Como estamos falando de Zend Framework, o 2 não vem ao caso, ficando apenas o excesso de peso. (e o ZF é o mais pesado entre os FW)

[Leozitho 81]

João, eu não sei se você conhece a fundo o ZendFramework, mas ele é um framework totalmente modular e que permite que você utilize somente o que realmente precisar e como desejar.

 

Sem dúvida o framework interfere no desempenho e, como eu disse no meu post #2, depende da estrutura de cada um.

 

Mas o que eu já notei em meus testes de benchmark é que uma das principais causas na perda de desempenho é a utilização de várias classes e extender umas das outras, apenas isso já atrasa o desempenho da aplicação em alguns milésimos de segundo. Por isso afirmo que a principal causa nessa perda de desempenho é a orientação a objetos.

 

Você já chegou a testar o tempo de execução das suas aplicações? Pergunto isso pois parece que você não se preocupa muito com desempenho, pois nas bibliotecas que você disponibiliza para iMasters você costuma usar require_once e caminhos relativos para incluir arquivos, e como se sabe uma boa prática para otimizar o sistema é utilizar caminhos absolutos e apenas require, para que o PHP não tenha que perder tempo verificando se o arquivo já foi incluído ou não.

[João Batista Neto 448]

João, eu não sei se você conhece o ZendFramework, mas ele é um framework totalmente modular e que permite que você utilize somente o que realmente precisar.

 

Sim, eu conheço o ZendFramework, li o código dele a fundo quando estava analisando padronização em diversos frameworks.

 

O que posso dizer é que, de longe, o código do ZFW é o mais bem escrito, padronizado e, sim, modular.

 

Contudo, mesmo modular, ele ainda carrega soluções para N casos genéricos que, mesmo não utilizando os módulos sociais e de APIs públicas e vários outros opcionais, o ZFW ainda é muito pesado. É talvez, entre todos, o mais bem escrito e certamente o mais pesado.

 

Procure, por mera curiosidade, fazer o seguinte benchmark:

 

Crie dois CRUD simples, apenas com um cadastro de pessoas com criação, leitura, edição e remoção de registros;

 

O primeiro utilizando o ZFW o segundo utilizando um MVC específico que você mesmo criou.

 

Utilize o ab nos dois e veja a diferença grotesca que há entre ambos.

 

Depois desse benchmark, faça o mesmo experimento com dois MVC específicos que você mesmo criou, porém um deles procedural e outro orientado a objetos.

 

Utilize o ab nos dois e você verá que a diferença é ínfima, praticamente irrelevante.

 

Ou seja, mesmo modular, o ZFW ainda é extremamente pesado e, em casos em que o desempenho é importante, ele pode ser a causa do fracasso da aplicação.

 

Você já chegou a testar o tempo de execução das suas aplicações? Pergunto isso pois parece que você não se preocupa muito com desempenho, pois nas bibliotecas que você disponibiliza para iMasters você costuma usar require_once e caminhos relativos para incluir arquivos, e como se sabe uma boa prática para otimizar o sistema é utilizar caminhos absolutos e apenas require, para que o PHP não tenha que perder tempo verificando se o arquivo já foi incluído ou não.

 

Veja, essas bibliotecas que disponibilizo são feitas para atender casos genéricos e também para diminuir o custo de desenvolvimento do desenvolvedor.

 

Quando eu desenvolvo uma aplicação eu procuro analisar várias coisas, entre elas o desempenho.

 

Existem dois casos:

 

1. Uma biblioteca pública, feita para desenvolvedores.

2. Uma aplicação de missão crítica.

 

No segundo caso, a análise de desempenho é levada em consideração e toda a aplicação modelada para tal.

 

Já o primeiro caso, a biblioteca é feita para facilitar o uso de alguma coisa, dessa forma, a praticidade é levada em consideração.

 

;)

[Leozitho 81]

Ok João, vou fazer o teste que você sugeriu. :)

 

Mas com sua experiência então você acha mais vantajoso criar um framework próprio se estiver preocupado com o desempenho da aplicação?

 

E com relação a usar require e include em vez de require_once e include_once, e usar caminhos absolutos que eu mencionei no post anterior, isso realmente traz um ganho de desempenho ou podemos considerar insignificante?

 

EDIT:

 

Desculpe, vi que você já respondeu com relação a segunta pergunta. :P

[João Batista Neto 448]

Mas com sua experiência então você acha mais vantajoso criar um framework próprio se estiver preocupado com o desempenho da aplicação?

 

Veja, a definição de framework é: Solução abstrata para N casos genéricos.

 

Ou seja, em aplicações de missão crítica, não se utiliza frameworks, seja um feito pode uma grande corporação como a Zend ou um feito por nós mesmos.

 

Uma aplicação de missão crítica deve ter todo seu core desenvolvido de forma específica; Quando mais específico for a solução, melhor será o desempenho da aplicação.

 

E com relação a usar require e include em vez de require_once e include_once, e usar caminhos absolutos que eu mencionei no post anterior, isso realmente traz um ganho de desempenho ou podemos considerar insignificante?

 

O require e require_once (e as versões include) funcionam mais ou menos assim:

 

<?php
function load( $file ) {
   	return file_get_contents( $file );
}

function load_once( $file ) {
   	static $loaded;

   	if ( $loaded == null ) {
           	$loaded = array();
   	}

   	if ( !isset( $loaded[ $file ] ) ) {
           	$loaded[ $file ] = file_get_contents( $file );
   	}

   	return $loaded[ $file ];
}

file_put_contents( 'test' , 'test' ); //criando o arquivo de teste

ob_start(); //para a saída não influenciar no teste

$time = microtime();

for ( $i = 0 ; $i < 10 ; ++$i ) {
   	var_dump( load( 'test' ) );
}

var_dump( 'Teste com load()' , microtime() - $time );

$time = microtime();

for ( $i = 0 ; $i < 10 ; ++$i ) {
   	var_dump( load_once( 'test' ) );
}

var_dump( 'Teste com load_once()' , microtime() - $time );

ob_end_flush(); //liberando a saída

 

A minha saída foi:

 

string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(16) "Teste com load()"
float(0.000376)
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(4) "test"
string(21) "Teste com load_once()"
float(0.000143)

 

Utilizando especificamente require e require_once, podemos fazer o seguinte experimento:

 

<?php
$content = '<?php var_dump( 10 );';

file_put_contents( 'test1.php' , $content );
file_put_contents( 'test2.php' , $content );

ob_start();

$time = microtime();

for ( $i = 0 ; $i < 10 ; ++$i ) {
   	require 'test1.php';
}

var_dump( microtime() - $time );

$time = microtime();

for ( $i = 0 ; $i < 10 ; ++$i ) {
   	require_once 'test2.php';
}

var_dump( microtime() - $time );

ob_end_flush();

 

No meu caso, a saída foi:

 

int(10)
int(10)
int(10)
int(10)
int(10)
int(10)
int(10)
int(10)
int(10)
int(10)
float(0.00048300000000001)
int(10)
float(8.9000000000006E-5)

 

;)

[Leozitho 81]

Como sempre explicações excelentes João, é bom poder contar com alguém com tanto conhecimento aqui no fórum. :joia:

 

Na verdade eu sempre soube que o ZF era o framework mais pesado, inclusive se olhar alguns posts antigos meus, poderá ver que eu sempre defendia a utilização de frameworks mais leves como o CI e Cake e fazia uma associação da loja Magento que foi baseada no ZF pra mostrar o quanto ele deixa a aplicação lenta.

 

Mas daí como já vi você comentando aqui no fórum que o CI é um framework digamos "ruim", pois não é muito bem orientando a objetos e tal, resolvi mudar de vez para o ZF que é muito mais robusto, segue padrões de desenvolvimento e é super bem documentado. Com relação ao desempenho acreditava que ele era pesado meramente por ser o mais bem estruturado e que eu poderia contornar este problema de outras formas, como com o uso de cache por exemplo.

 

Um das principais vantagens que eu vejo em se usar frameworks é que cada módulo já foi testado por milhares de programadores em todo o mundo, então as chances de ter alguma falha ou brecha de segurança por exemplo são quase nulas, pois quando se tem são rapidamente detectadas e corrigidas.

 

Infelizmente no momento eu não tenho um framework próprio com os mesmos recursos do ZF pra fazer uma comparação justa como você sugeriu, mas com base nas suas explicações eu entendo que não há problema em continuar utilizando o ZF em aplicações que não exijam tanto desempenho, mas se a aplicação exigir bastante desempenho o melhor é abrir mão de qualquer framework. ;)

 

Valeu João!

[João Batista Neto 448]

Mas daí como já vi você comentando aqui no fórum que o CI é um framework digamos "ruim", pois não é muito bem orientando a objetos e tal, resolvi mudar de vez para o ZF que é muito mais robusto, segue padrões de desenvolvimento e é super bem documentado. Com relação ao desempenho acreditava que ele era pesado meramente por ser o mais bem estruturado e que eu poderia contornar este problema de outras formas, como com o uso de cache por exemplo.

 

O grande problema do CI é o suporte legado.

 

O desenvolvimento do CI é amarrado pela EllisLab por conta desse suporte e isso faz com que novos recursos demorem para ser incorporados ao core do fw; Justamente por conta disso, muitos colaboradores do CI abandonaram o fw para criar um novo, chamado Kohana.

 

Um das principais vantagens que eu vejo em se usar frameworks é que cada módulo já foi testado por milhares de programadores em todo o mundo, então as chances de ter alguma falha ou brecha de segurança por exemplo são quase nulas, pois quando se tem são rapidamente detectadas e corrigidas.

 

Concordo contigo em casos genéricos, mas quando trabalhamos com o desenvolvimento de uma aplicação muito específica, dificilmente o fw, qualquer que seja ele, dará suporte para isso.

 

Por exemplo, imagine que você precise desenvolver uma aplicação para um host, o framework ajudará com o MVC ou HMVC ou qualquer outra arquitetura que o fw suporte, mas a integração com os servidores será por sua conta pois nenhum fw oferece suporte para integração e criação de serviços no servidor.

 

Como você, invariavelmente, precisará criar tal suporte, a generalização do fw não lhe ajudará e você precisará testar sua aplicação para garantir a integridade e funcionamento dela.

 

Por outro lado, se você for desenvolver um site que consiste basicamente em CRUD, então o FW é altamente recomendável justamente por ter, em seu core, funcionalidades para atender esse quesito.

 

Framework é uma ferramenta, apenas isso, e como tal deve ser utilizada no momento adequado; Se você pensar no FW como solução, você certamente terá um problema em casos específicos.

 

:D

[hinom 5]

é como Eike Batista diz "visão 360, visão 360" rsss

[visitante_php 0]

me desculpem entrar na discussao, mas um certo ano, eu criei meu proprio FW por nao entender e aprender os do mercado, e fia uma comparacao com um codigo procedural , eu usei este FW pra criar um determinado site e o comparei com o codigo anterior procedural feito por outro programador...e a diferença de performance do meu FW foi absurdamente melhor q o codigo procedural, como seria neste caso?