Desempenho vRaptor

Caros,

Gostaria de saber se o vRaptor é indicado para aplicações com uma quantidade grande de acessos simultâneos.
Como ele se sai nesses casos?
Alguém tem algum case?

Obrigado,

A princípio ele é tão bom quanto qualquer outro framework baseado em Servlets…

O problema de ter uma grande quantidade de acessos simultâneos não vai ser resolvido por usar o Framework X ou o Framework Y. Para resolver o problema você vai ter que pensar em escalar a aplicação horizontalmente, e existem alguns jeitos de fazer isso…

um deles é replicar a sua aplicação em vários servidores, e deixar um load balancer na frente, dividindo as requisições entre os vários servidores…

outro jeito é construir sua aplicação dentro de um cloud, como o Google App Engine, e o VRaptor já tem um blank-project específico pra rodar no GAE…

o que vc precisa se preocupar quando escolhe um framework é se ele é produtivo, e se ele te ajuda a implementar os requisitos da sua aplicação… Quanto a performance e escalabilidade, isso é maior responsabildade dos servidores que vc usa, tanto o tipo, qto a quantidade deles…

Lucas,

Concordo com o que você falou, mas o framework interfere no desempenho.
Um exemplo é o JSF, ele não é indicado para aplicações com grande número de acessos.
Que da pra fazer eu sei que d, mas vai precisar usar muito mais da maquina.
E é isso que eu to querendo saber, qual tem um desempenho melhor/precisa de menos recurso da maquina?

Obrigado pela resposta.

o VRaptor te permite fazer aplicações stateless (coisa que o JSF não deixa), que geralmente têm a performance melhor…
o stateless que eu digo é sobre usar HttpSession…

outra coisa é que o vraptor não sobrecarrega o protocolo Http com urls gigantescas, ou com muitos parâmetros desnecessários, ou seja, o tamanho do Request e do Response é praticamente só dependente da sua aplicação…

a única outra coisa que prejudicaria a performance seria o processamento do lado do servidor, que aí sim depende do VRaptor por que ele é que trata as requisições… Eu não conheço ninguém que tenha feito um profiling do vraptor, mas existem algumas aplicações grandes usando e não ouvi reclamações sobre performance…
de qqer forma o tempo de processamento de uma requisição no servidor é de ordem de grandeza menor do que a da transferência da rede, então não acho que tenha um impacto grande na performance…

Pelo que o framework se propõe a fazer … não tem nem como gerar problemas para você.
Se quer usar e acha que vai ser util acho que pode ir em frente sem medo.

Olá pessoal,

na empresa onde trabalho estamos estudando a troca do framework web utilizado e talvez o único grande ponto de questionamento ainda existente seja referente à questão do desempenho. Nesse post, até o momento, falou-se em relação ao desempenho do VRaptor3 frente à quantidade de acessos. E em relação ao volume de dados manipulados? Alguém tem informação em relação a isso? Tanto o posicionamento dos desenvolvedores quando de usuários do framework que passaram (ou não passaram) por problemas nesse sentido seriam muito importantes.

Muito obrigado.

Você diz em relação a requisições com muitos dados, ou lógicas que processam muitos dados no servidor?

[quote=smillodont]Olá pessoal,

na empresa onde trabalho estamos estudando a troca do framework web utilizado e talvez o único grande ponto de questionamento ainda existente seja referente à questão do desempenho. Nesse post, até o momento, falou-se em relação ao desempenho do VRaptor3 frente à quantidade de acessos. E em relação ao volume de dados manipulados? Alguém tem informação em relação a isso? Tanto o posicionamento dos desenvolvedores quando de usuários do framework que passaram (ou não passaram) por problemas nesse sentido seriam muito importantes.

Muito obrigado.[/quote]

Como o amigo acima disse depende de qual a tarefa efetuada com os seus dados …
Se tiver processamento pesado como caculos e outros … se forem muitos muitos dados mesmo … java é meio pesada para fazer isso online.

No caso de exibir uma lista grande na tela, antes de ver uma framework veja questões de usabilidade.

No caso de muitos dados na requisição isto é relativo mais nenhum framework vai degradar seu ambiente por você passar muitos dados de entrada num aplicativo.(ou não deveria)

Eu tenho um case muito bom que é um software para gestão escolar pública, que até já escrevi sobre isso há algum tempo aqui no guj.

O projeto todo roda aproximadamente 2 milhões de consultas diárias em uma base pgsql que atualmente está em 580 tabelas. Os sistemas já implantados rodam aproximadamente 50 usuários simultâneos, porém esses poucos usuários fazem tarefas muito pesadas. Época de fechamento de ano letivo o sistema roda aproximadamente 12 milhões de instruções no banco de dados, algumas em batch na madrugada para não sobrecarregar o sistema.

Todo o projeto roda em um módulo web usando vraptor 3.1 e um módulo EJB remoto. Hoje a camada web está em um cluster ativo/passivo com apenas duas instâncias já que o vraptor é muito leve. Já o módulo EJB remoto está em um cluster maior (varia de cliente para cliente, mas gira em torno de 20 à 30 instâncias).

O vraptor atendeu muito bem todas as necessidades do projeto, inclusive trabalhando transparente com json para funcionalidades de ajax. Houve alguns pontos que o vraptor não atendeu minhas necessidades, como por exemplo um exception handler inteligente, porém foi super simples implementar. Há muitos tópicos meus aqui no guj com ajuda do Lucas e do Paulo nessas customizações.

Uma coisa que eu senti falta foi de uma taglib mais inteligente, já que a waffle é muito fraca. Mas mesmo assim os pontos positivos do vraptor se sobrepoem a esse único ponto negativo e o que fizemos foi customizar algumas tags nos pontos onde a waffle não atende.

Enfim, notei que o vraptor tem um excelente desempenho tanto no tempo de desenvolvimento (você leva pouco tempo para fazer um usecase) como rodando em produção (performance muito boa). Falando por alto creio que o vraptor seja um dos mais leves frameworks para web. Pelo menos não consigo imaginar um caso que o vraptor possa estar mais lento que um JSF (embora JSF tenha outro foco) ou até mesmo que um Struts.

Obrigado pessoal, acredito que a resposta de garcia-jj já exemplificou o bom desempenho esperado.