JSF - Performance e Escalabilidade

Bom, o conceito de drag-n-drop pra java (solucao web) nao nasceu com JSF. Agora sobre o assunto de performance, não acredito que setando o SAVE STATE do JSF no servidor vai prejudicar alguma coisa. Claro que, isso vai do desenvolvedor, depende doq o caboco coloca nos componentes, se tu mandar um select que retorna 400000 mil linhas e salvar em um componente, ai tu mereceu.

Salvar os estados dos componentes no cliente tambem nao é nenhum problema, estamos falando de 100kb? Dificil dar isso (ver o depende anterior). Quando vou fazer um sistema, eu preocupo mais com a satisfacao do usuario, problema de desempenho e performance com JSF vai depender mais do seu servidor.

Eu criei o site da minha empresa emcima do JSF (myfaces 1.1.5) com JPA, hibernate3, tiles, ajax etc… estou salvando o estado dos componentes no cliente, troquei pro servidor e nao notei melhoria no tempo de cada request pelo cliente.

Se voce quiser dar uma olhada, o site eh http://www.pimpas.net

Flwz.

Bom, o conceito de drag-n-drop pra java (solucao web) nao nasceu com JSF.

Em nenhum momento disse isso.

Quando vou fazer um sistema, eu preocupo mais com a satisfacao do usuario, problema de desempenho e performance com JSF vai depender mais do seu servidor.

Concordo plenamente. Mas a satisfação do usuário só está ligada a um layout bonito? Acredito que não.

Eu uso JSF nos meus projetos, não estou aqui para dizer que é uma tecnologia ruim, de jeito nenhum, estou aqui para levantar uma reflexão.

Os custos de um servidor para manter aplicações escaláveis em JSF é consideravelmente maior do que utilizando paradigmas tradicionais de desenvolvimento web. Estou chamando de escalável, uma aplicação que suporte, no mínimo, 500 sessões abertas ao mesmo tempo no servidor.

Uma aplicação onde só 10 usuários acessam simultaneamente, raramente teremos problemas ao optar pela tecnologia A ou B, mas com o crescimento do uso os problemas aparacem, e aí assim, vemos o que reamente a tecnologia A ou B tem de melhor.

Por exemplo, acho o Rails fantástico. Ele te dá liberdade sem ficar te “engessando”. Vc pode alterar todos os arquivos que ele gera e personalizar absolutamente tudo. Já vi aplicações muito boas feita utilizando o Rails, mas ainda não vi nenhuma aplicação de grande porte. Será que o framework é escalável? Só o tempo vai dizer.

Outro exemplo muito bom é o do Orkut. Foi feito, inicialmente, todo em .Net mas com o crescimento do número de usuários o framework não ofereceu a escalabilidade necessária. Qual foi a solução adotada? Migrar tudo para Java (mantiveram a extensão aspx). O processo de migração levou aproximadamente 1 ano.

Não podemos esquecer que várias empresas, inclusive a Sun, não vive somente do mercado de softwares. O principal mercado é o de infra-estrutura. Pense nisso e tire suas próprias conclusões.

Na boa, se você precisa de uma aplicação realmente escalável em uma server farm a primeira coisa a se fazer é evitar que o estado seja salvo nos servidores web (a não ser que você use algum esquema de cluster de sessões). Seja em JSF ou seja em Rails, a lógica é a mesma, não é o framework X ou Y que vai resolver o seu problema, é como você usa ele.

Na boa, se você precisa de uma aplicação realmente escalável em uma server farm a primeira coisa a se fazer é evitar que o estado seja salvo nos servidores web (a não ser que você use algum esquema de cluster de sessões). Seja em JSF ou seja em Rails, a lógica é a mesma, não é o framework X ou Y que vai resolver o seu problema, é como você usa ele.

Exatamente, passei por um problema desses com ASPX - fazendo análise da arquitetura para um cliente.

Ele tem uma solução de análise de financiamento e roda via Web, armazenando estado na sessão. Sua arquitetura é baseada em Apache e não IIS com servidor embutido para resulução dos componentes.

Ele tinha restrição de memória 2GB e não tinha cluster de sessão.

Advinha o que aconteceu com a aplicação, à medida que o número de usuários simultâneos cresceu ? ( empresa crescia num rítmo de 148% ao ano) .

Crash total…Você pode até ter essa solução, mas precisa saber quanto cada objeto consome e quantos usuários simultâneos sua aplicação aguenta, para prever um sistema escalável e desenhá-lo assim.

Eu criei o site da minha empresa emcima do JSF (myfaces 1.1.5) com JPA, hibernate3, tiles, ajax etc… estou salvando o estado dos componentes no cliente, troquei pro servidor e nao notei melhoria no tempo de cada request pelo cliente.

Se voce quiser dar uma olhada, o site eh http://www.pimpas.net

Uma aplicação onde só 10 usuários acessam simultaneamente, raramente teremos problemas ao optar pela tecnologia A ou B, mas com o crescimento do uso os problemas aparacem, e aí assim, vemos o que reamente a tecnologia A ou B tem de melhor.

Na boa, se você precisa de uma aplicação realmente escalável em uma server farm a primeira coisa a se fazer é evitar que o estado seja salvo nos servidores web (a não ser que você use algum esquema de cluster de sessões). Seja em JSF ou seja em Rails, a lógica é a mesma, não é o framework X ou Y que vai resolver o seu problema, é como você usa ele.

WilliamSilva:

Eu criei o site da minha empresa emcima do JSF (myfaces 1.1.5) com JPA, hibernate3, tiles, ajax etc… estou salvando o estado dos componentes no cliente, troquei pro servidor e nao notei melhoria no tempo de cada request pelo cliente.

Se voce quiser dar uma olhada, o site eh http://www.pimpas.net

Não notei nada em seu site que fosse em “JSF”, pelo contrario só página de apresentação.

Uma aplicação onde só 10 usuários acessam simultaneamente, raramente teremos problemas ao optar pela tecnologia A ou B, mas com o crescimento do uso os problemas aparacem, e aí assim, vemos o que reamente a tecnologia A ou B tem de melhor.

Já desenvolvi aplicações em JSF p/ intranet e enquanto em tinha o servidor sobre meu controle tudo bem mais depois que joguei para uma extranet foi um desgaste total, mais não posso dar um parecer porque foi na versão 1.0 do JSF e hoje muita coisa mudou no framework atual.

Na boa, se você precisa de uma aplicação realmente escalável em uma server farm a primeira coisa a se fazer é evitar que o estado seja salvo nos servidores web (a não ser que você use algum esquema de cluster de sessões). Seja em JSF ou seja em Rails, a lógica é a mesma, não é o framework X ou Y que vai resolver o seu problema, é como você usa ele.

Legal, mais o ideal se ele fosse " thread safe" e eu pudesse trabalhar com as requisições, mais acho que isso é outra questão.
sds.

Todo o site foi feito emcima das tecnologias que eu citei, a parte “sobre” por exemplo, é uma solução jsf + ajax (os sub-menus) e toda a parte de admin. O site ainda não esta finalizado, mas esse é o segundo que eu faço utilizando essas tecnologias, e como eu disse anteriormente, eu salvo os estados dos componentes no cliente e nunca tive problema com isso (performance etc).

WilliamSilva:

Legal, mais o ideal se ele fosse " thread safe" e eu pudesse trabalhar com as requisições, mais acho que isso é outra questão.
sds.

Não entendi o “thread-safe” aqui, servlets não são thread safe (graças a deus!) e isso é um dos motivos pelos quais é possível criar aplicações Java escaláveis, se os servlets fossem thread safe só uma thread poderia chamar um servlet por vez.

Kenobi:

[
Exatamente, passei por um problema desses com ASPX - fazendo análise da arquitetura para um cliente.

Ele tem uma solução de análise de financiamento e roda via Web, armazenando estado na sessão. Sua arquitetura é baseada em Apache e não IIS com servidor embutido para resulução dos componentes.

Ele tinha restrição de memória 2GB e não tinha cluster de sessão.

Pois é, e sempre pode ser pior, é só você considerar que se você está fazendo cluster de sessão, vai terminar fazendo cluster de banco de dados também, então são dores de cabeça dobradas, já que você vai ter que dar conta de gerenciar DOIS clusters completamente diferentes e, provavelmente, com ferramentas completamente diferentes.

Maurício Linhares:

Kenobi:

[
Exatamente, passei por um problema desses com ASPX - fazendo análise da arquitetura para um cliente.

Ele tem uma solução de análise de financiamento e roda via Web, armazenando estado na sessão. Sua arquitetura é baseada em Apache e não IIS com servidor embutido para resulução dos componentes.

Ele tinha restrição de memória 2GB e não tinha cluster de sessão.

Pois é, e sempre pode ser pior, é só você considerar que se você está fazendo cluster de sessão, vai terminar fazendo cluster de banco de dados também, então são dores de cabeça dobradas, já que você vai ter que dar conta de gerenciar DOIS clusters completamente diferentes e, provavelmente, com ferramentas completamente diferentes.

Esse é um problema que talvez você não tenha com tecnologias como Flex para manter estado, já que você delega ao cliente.

Ainda não utilizei Flex, mas estou pensando até para uma solução que precisará escalar muito e gostaria de opinião de alguém sobre a tecnologia .

Kenobi:

Esse é um problema que talvez você não tenha com tecnologias como Flex para manter estado, já que você delega ao cliente.

Ainda não utilizei Flex, mas estou pensando até para uma solução que precisará escalar muito e gostaria de opinião de alguém sobre a tecnologia .

Pois é, se você esquecer que tem uma aplicação web com sessões lá do outro lado, não vai ter problema não, desse jeito não importa muito a tecnologia que você está usando, seja Swing, Silverlight, Flex ou whatever.

Mas o Flex é uma boa escolha sim, não é maravilhosamente fácil de usar, mas pra esse tipo de problema ele é uma mão na roda.

Mas o Flex é uma boa escolha sim, não é maravilhosamente fácil de usar, mas pra esse tipo de problema ele é uma mão na roda.

Realmente é uma mão na roda, principalmente se vc utilizar SOA.

Dê uma olhada nesse site, compara o total de gasto computacional se salvar o estado dos componentes no servidor e no cliente: http://www.go-java.com/blog/2007/01/23/1169557003064.html