Pessoal, como presente de natal tivemos a chegada da release 1.2 tão esperada por muitos do CakePHP.
Os detalhes podem ser vistos em http://bakery.cakephp.org/articles/view/the-gift-of-1-2-final.
Abraços e bons projetos a todos.
Pessoal, como presente de natal tivemos a chegada da release 1.2 tão esperada por muitos do CakePHP.
Os detalhes podem ser vistos em http://bakery.cakephp.org/articles/view/the-gift-of-1-2-final.
Abraços e bons projetos a todos.
Pessoal,
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:
Minhas opiniões quanto os resultados:
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.
Ontem foi lançada a versão candidata a release número 4. As principais modificações em relação ao RC3 são os massivos testes automatizados, aumentando ainda mais a confiabilidade do core.
Mais informações podem ser vistas em http://bakery.cakephp.org/articles/view/rc4-close.
Pessoal,
Estava pensando sobre o desenvolvimento de um sistema modular (um ERP, CRM, etc), vendido em partes para o cliente e que o código fosse deixado no cliente (nem que fosse criptografado com as diversas ferramentas que há disponível por aí…). Dai pensei, como fazer isso com o CakePHP?!
Pensando, achei que fosse legal criar cada módulo como um plugin, inclusive alguns recursos básicos do sistema, como a parte de autenticação (login). Deixar a ‘app’ como um barramento da aplicação, fornecendo components, helpers, layouts, css/js, vendors, etc. Essa parte funcionaria como uma infra estrutura do sistema, onde as rotas poderiam ser criadas dinâmicamente pelo AppController do plugin ou usar as rotas diretamente do sistema (plugin/controller/action/params).
Hoje o CakePHP dispões de várias funções para identificar se o app possui um componente ou outro plugin instalado, podendo os plugins “se conversarem”. O comando App::listObjects(’Plugin’), por exemplo é fantástico para saber se um outro módulo também está instalado. Assim não precisaria cadastrar cada módulo numa base de dados, que poderia ser manipulada pelo cliente ou coisa do genero.
O mesmo poderia ser aplicado a uma empresa que possui diversos softwares, não necessariamente inteligados (em módulos). Onde todas as aplicações teriam um ambiente de desenvolvimento comum (barramento) e cada aplicação seria um plugin. Isso reduziria a quantidade de código e, consequentemente, o tamanho da aplicação nos clientes que tiverem mais de uma aplicação.
O que acham? Já passaram por algo assim?
Com o crescimento do uso de AJAX, da maioria dos frameworks de JavaScript (jQuery, Prototype, mooTools, YUI, ExtJS, …) e de uma dúvida no Groups do Google (Action que renderize apenas o layout, sem necessidade de uma view), resolvi escrever um post falando sobre como usar JSON no CakePHP de forma automática para retorno dos dados, sem precisar gerar um arquivo de view para cada action e que não fere o MVC.
A Solução
Para solucionar o caso, achei que o melhor jeito seria criando uma classe de View nova. A classe View do CakePHP ela sempre procura um arquivo de view, além do template. Com a nova classe, seria feita a renderização ali mesmo, sem a necessidade de novos arquivos.
A classe que criei (JsonView) pode ser baixada aqui. Ela deve ser colocada na pasta views de da sua aplicação (nenhuma sub-pasta) com o nome de json.php. Ou seja, no final, você terá o caminho app/views/json.php.
Como Usar
Para usar é bem simples. No seu controller, quando você for retornar um código em JSON, basta alterar a variável $view do controller para usar a nova classe. Além disso, os dados que você quer que retorne, devem ser setados com o nome ‘json‘ no seu controller. Caso não seja, ele vai renderizar normalmente. Exemplo de uso no controller:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | class UsuariosController extends AppController { var $uses = array('Usuario', 'Grupo'); function index($json = false) { $this->set('usuarios', $this->Usuario->find('list')); if ($json) { $this->view = 'Json'; $this->set('json', 'usuarios'); } } function multilista($json = false) { $this->set('usuarios', $this->Usuario->find('list')); $this->set('grupos', $this->Grupo->find('list')); if ($json) { $this->view = 'Json'; $this->set('json', array('usuarios', 'grupos')); } } } |
Neste caso, quando o parâmetro de index não for true, ele vai renderizar como se fosse uma requisição normal. Caso passe como true, ele irá renderizar como JSON. Já no método multilista, além do parâmetro para verificar se é JSON, ele passa um array de variáveis para a view JSON, assim a classe irá renderizar mais de uma variável.
Outra maneira de se fazer é definir a variável $view da classe diretamente com ‘Json’ (assim como foi feito com $uses no exemplo). Assim, sempre que você der um set na variável ‘json’, a classe da View se liga e renderiza em json, caso contrário mantém o normal.
Conclusão
Este é um método fácil e rápido de renderizar as requisições JSON, sem precisar criar um arquivo para cada requisição e sem precisar de muito código (tanto no controller, quanto na view).
O código que fiz, é compatível com PHP 4 e 5, então é possível usar com o CakePHP sem medo em qualquer versão de PHP.
Abraços e bom uso.
Dicas são sempre bem vindas.
Boas novas, cakers!
Saiu hoje a nova versão do CakePHP 1.2, através da release candidate (RC) 1, usando a revisão 7119.
As maiores alterações são alterações no modo de utilizar as condições e colocar vários métodos em desuso.
Para quem quiser mais informações sobre o lançamento, consulte o link oficial (no Bakery). Quem quiser fazer o download agora, clique aqui.
Abraços e bom uso para todos.
Powered by WordPress