Como melhorar um sistema de grande porte

5.000 x 100.000 = 500.000.000 transações por mês (23 milhões de transações por dia?) Não tem uma continha errada aí?

23 milhões de transações por dia parece um sistema de um banco de grande porte.

entanglement:

5.000 x 100.000 = 500.000.000 transações por mês (23 milhões de transações por dia?) Não tem uma continha errada aí?

23 milhões de transações por dia parece um sistema de um banco de grande porte.

Olha foi o que o cliente me passou, mas o seguinte

23 milhões / 5000 = 4600 transações por dia por usuario, digamos que ele trabalha 8 horas por dia

4600 / 8 = 575 transacoes por hora

Sendo que a transação propriamente dita, é:
ver um relatorio colocar o valor no campo certo e apertar um botao
Acho que ta rolando, neh?

É realmente conversando com o pessoal aqui, as transacoes, estao dentro da normalidade de um sistema grande,

Alguem tem algum material que eu possa ler???

Blz?

Primeira coisa… o que significa usuários simultânios para você? E para o cliente? o que significa?

Já tive problemas em relação a esse tipo de nomenclatura… acabo hoje usando usuários logados (não necessariamente fazendo a mesma operação) e usuários concorrentes (usuários realizando operações simultâneas no sistema).

De qualquer forma aplicações com muitos usuários devem ser desenvolvidas com o objetivo de serem escaláveis. Desta forma acabo partindo para EJB mesmo.

Isso resolve os problemas? NÃO!

O ideal é investir em treinamento da equipe para JPA e JSF. O mau uso desses frameworks causam problemas em aplicações pequenas…imagina em aplicações grandes…

Outro ponto… análise de plano de execução das queries geradas pelo hibernada para as funcionalidades principais e mais pesadas…acaba ajudando na geração de consultas melhores.

Citei algumas coisas, mas tem muitos pontos a serem tratados, alguns dependentes das característica da aplicação.

Espero ter ajudado.

felipef:

Bom dia pessoal

Então andei lendo, estudando e etc, mas ainda não consegui fazer o que preciso

Na minha empresa estamos construindo um sistema JEE6, utilizando

Primefaces 3.4
JSF 2.0
facelets
Spring 3.1
Hibernate 3 com JPA

Servidor de app Glassfish Server Open Source Edition 3.1.2.2 (build 5)

Banco de dados SQL server

E futuramente ela deve ser fragmentada(modularizada), ou seja, ela sera uma pequena parte de um outro grande sistema, estou pensando em utilizar web-fragment(servlet 3.0)

Eu ja sabia que a aplicação deveria suportar muitos usuários, mas hoje eu tive um numero

A aplicação deve suportar 5 mil usuários simultâneos, e deve suportar para cada usuário 100 mil transações por mês

E deve ser rápido, hehehe

Então a minha pergunta é:
O que posso melhorar nisso,

Banco de dados? Oracle, NoSQL, MongoDB
Servidor de aplicação, alguma solução paga?

configuração do hibernate para melhorar as queries?

Não sei se consegui ser claro, mas qualquer coisa vamos conversar, estou aberto a sugestões

Olha, a “receita de bolo” pode até servir, mas tambem vem a ser um tiro no pé se voce nao tiver clareza no que realmente precisa.

O foco inicial nao deve ser a montagem de uma arquitura “que tende a funcionar na media”, mas customizada à realidade do projeto.

Por exemplo:
-> a depender do modelo de telas, eu cortaria fora o JSF pra ganhar em flexibilidade
-> a depender das reais necessidades de recursos de banco, eu cortaria SQL Server e iria para postgres
-> alguns algoritmos ou funções do sistema podem requer muito acesso a dados que fique melhor servido com NoSQL, mas a menos desta necessidade eu nao embarcaria na ideia (teria que ser bem justificado)
-> voce realmente precisa da casca de JPA ou pode partir direto pra api de hibernate, que por sinal é mais limpa e mais robusta?
-> voce precisa se comunicacao com outros sistemas? sob quais requisitos (segurança, performance etc)?
-> precisa de mensageria?

e por ai vai.
perceba, portanto, que mais importante do que elencar possiveis tecnologias da moda, o mais importante é atender bem ao negocio.

felipef:

entanglement:

5.000 x 100.000 = 500.000.000 transações por mês (23 milhões de transações por dia?) Não tem uma continha errada aí?

23 milhões de transações por dia parece um sistema de um banco de grande porte.

Olha foi o que o cliente me passou, mas o seguinte

23 milhões / 5000 = 4600 transações por dia por usuario, digamos que ele trabalha 8 horas por dia

4600 / 8 = 575 transacoes por hora

Sendo que a transação propriamente dita, é:
ver um relatorio colocar o valor no campo certo e apertar um botao
Acho que ta rolando, neh?

Como melhorar um sistema de grande porte??

Aqui optamos por reescrever tudo, dado que o modelo antigo estava uma carroça (joins!!!) e os conceitos não estavam adequados.

Teríamos perdido muito tempo e os resultados teriam sido ruins se opção fosse a de melhorar o que existia.

Hoje trabalhamos tranquilamente com uma aplicação que já processa o dobro de requisições em relação à antiga, com estimativa de alcançar 20 vezes mais.

andre_salvati:

felipef:

entanglement:

5.000 x 100.000 = 500.000.000 transações por mês (23 milhões de transações por dia?) Não tem uma continha errada aí?

23 milhões de transações por dia parece um sistema de um banco de grande porte.

Olha foi o que o cliente me passou, mas o seguinte

23 milhões / 5000 = 4600 transações por dia por usuario, digamos que ele trabalha 8 horas por dia

4600 / 8 = 575 transacoes por hora

Sendo que a transação propriamente dita, é:
ver um relatorio colocar o valor no campo certo e apertar um botao
Acho que ta rolando, neh?

Como melhorar um sistema de grande porte??

Aqui optamos por reescrever tudo, dado que o modelo antigo estava uma carroça (joins!!!) e os conceitos não estavam adequados.

Teríamos perdido muito tempo se opção fosse a de melhorar o que existia.

a pergunta em si me parece generica demais pra se poder dar qualquer direcionamento apropriado.
Melhorar em que? tempo de reposta? acesso a dados? quais sao os gargalos?
primeiro identique os problemas, ou eventuais futuros problemas, que sao ESPECIFICOS do projeto, pra dai ataca-los cada um.

andre_salvati, voce pode aproveitar a ocasiao e relatar o seu case, quais eram os problemas, e como conseguiu os beneficios mencionados?

icarocd:

andre_salvati:

felipef:

entanglement:

5.000 x 100.000 = 500.000.000 transações por mês (23 milhões de transações por dia?) Não tem uma continha errada aí?

23 milhões de transações por dia parece um sistema de um banco de grande porte.

Olha foi o que o cliente me passou, mas o seguinte

23 milhões / 5000 = 4600 transações por dia por usuario, digamos que ele trabalha 8 horas por dia

4600 / 8 = 575 transacoes por hora

Sendo que a transação propriamente dita, é:
ver um relatorio colocar o valor no campo certo e apertar um botao
Acho que ta rolando, neh?

Como melhorar um sistema de grande porte??

Aqui optamos por reescrever tudo, dado que o modelo antigo estava uma carroça (joins!!!) e os conceitos não estavam adequados.

Teríamos perdido muito tempo se opção fosse a de melhorar o que existia.

a pergunta em si me parece generica demais pra se poder dar qualquer direcionamento apropriado.
Melhorar em que? tempo de reposta? acesso a dados? quais sao os gargalos?
primeiro identique os problemas, ou eventuais futuros problemas, que sao ESPECIFICOS do projeto, pra dai ataca-los cada um.

andre_salvati, voce pode aproveitar a ocasiao e relatar o seu case, quais eram os problemas, e como conseguiu os beneficios mencionados?

Hoje não temos gargalo pois o sistema estamos começando a desenvolver, mas quando implantarmos, nao poderemos ficar correndo atras e corrigindo, tem q sair da nossa mao, ja bombando!!

O que falo em melhorar, é: utilizo essas APIs, sera que não utilizar alguma, como ja foi mencionado, não é melhor, sera q alterar de SQL Server para Oracle nao é melhor?

Sim, teremos alguns processos que vamos utilizar NoSql, mas como devo medir que e determinada situação haverá a necessidade?

thiagomont:

Blz?

Primeira coisa… o que significa usuários simultânios para você? E para o cliente? o que significa?

Já tive problemas em relação a esse tipo de nomenclatura… acabo hoje usando usuários logados (não necessariamente fazendo a mesma operação) e usuários concorrentes (usuários realizando operações simultâneas no sistema).

De qualquer forma aplicações com muitos usuários devem ser desenvolvidas com o objetivo de serem escaláveis. Desta forma acabo partindo para EJB mesmo.

Isso resolve os problemas? NÃO!

O ideal é investir em treinamento da equipe para JPA e JSF. O mau uso desses frameworks causam problemas em aplicações pequenas…imagina em aplicações grandes…

Outro ponto… análise de plano de execução das queries geradas pelo hibernada para as funcionalidades principais e mais pesadas…acaba ajudando na geração de consultas melhores.

Citei algumas coisas, mas tem muitos pontos a serem tratados, alguns dependentes das característica da aplicação.

Espero ter ajudado.

Sim, são usuarios utilizando o sistema e executando as mesmas operações

Sobre EJB, não sei se pode melhorar, teria q estudar mais a fundo, não conheco muito EJB e não gosto, mas se tiver que usar, vamos lá!!!

Se voce nao precisa de funcionalidades especificas de postgres ou oracle, que inclusive nao pudessem ser aplicadas em bancos gratuitos, eu nao vejo sentido em pagar o preço (caro, por sinal). Quanto mais puder evitar o vendor lock-in, melhor.

A utilização de nosql depende de caracteristicas especificas. Voce precisa entender muito bem quando usar ou nao. Por exemplo, há previsao de situacoes com alto volume e frequente de uso de dados? Voce está disposto a pagar o preço de perder alguma ou algumas das propriedades de ACID pra ganhar em escalabilidade? Idem para perder em normalização? Você precisa de sharding? De replicação? replicação master master?
Se ainda não tiver respostas, ou investiga melhor ou começa de um modo que depois nao tenha muito retrabalho. Nao vejo outras opcoes.

Sobre a colocação de “quando implantarmos, nao poderemos ficar correndo atras e corrigindo, tem q sair da nossa mao, ja bombando”, sua ideia está correta, porem sem conhecer as necessidades fica dificil voce fazer uma boa ‘adivinhacao’. Geralmente os BDUF’s tendem ao fracasso.

Uma boa arquitetura de software TEM QUE levar em consideração os requisitos funcionais e, não menos importantes, os não funcionais. Isso deve vir antes de gosto pessoal ou vontade de usar X ou Y.

icarocd

Pq? O que não consigo fazer com JSF?

Se depender de mim, não vou utilizar Sql Server e postgres tb nao, para isso iria partir para o Oracle

Sim, mas como eu meço que em determinada operação é necessario utizar NoSQL?

Vou avaliar

não é comunicação, mas um portal de varios sistemas que essa empresa ira utilizar

Por ex.

Eles possuem o sistema x, y e z, que fazem coisas totalmente diferentes

Mas eles querem ter apenas 1 login para acessar todos eles

Por isso pensei em fazer 1 projeto web para o login e controle de acesso, acessando um determinado banco de dados, e a partir disso, ira acessar os outros sistemas cada um com o seu banco de dados, entao pensei que esses outros sistemas poderia utiulizar web-fragment

Graças a deus e bom para o cliente, dinheiro não é problema, hehehe, se tiver que pagar será pago, pena que nao chega no meu bolso( problemas dos programadores)

A utilização de nosql depende de caracteristicas especificas. Voce precisa entender muito bem quando usar ou nao. Por exemplo, há previsao de situacoes com alto volume e frequente de uso de dados? Voce está disposto a pagar o preço de perder alguma ou algumas das propriedades de ACID pra ganhar em escalabilidade? Idem para perder em normalização? Você precisa de sharding? De replicação? replicação master master?
Se ainda não tiver respostas, ou investiga melhor ou começa de um modo que depois nao tenha muito retrabalho. Nao vejo outras opcoes.

É agora pensando por isso é meio arriscado perder consistências entre outras coisas, para isso terei que estudar muito(ainda nao chegamos no momento de desenvolver as operações complexas que vao necessitar transacoes com alta performance.

Sobre a colocação de “quando implantarmos, nao poderemos ficar correndo atras e corrigindo, tem q sair da nossa mao, ja bombando”, sua ideia está correta, porem sem conhecer as necessidades fica dificil voce fazer uma boa ‘adivinhacao’. Geralmente os BDUF’s tendem ao fracasso.

Uma boa arquitetura de software TEM QUE levar em consideração os requisitos funcionais e, não menos importantes, os não funcionais. Isso deve vir antes de gosto pessoal ou vontade de usar X ou Y

Por isso iniciamos sem saber o volume de usuario que utlizarão o sistema, e agora que sabemos estamos tentando estudar para saber qual a melhor alternativa

Desculpe a demora para responder.

Considerando que são de fato 5000 usuários acessando o sistema no mesmo instante, recomento o uso de EJB mesmo.

Em relação ao JPA2 x Hibernate, não sei availiar se a API do hibernate é mais robusta ou não…

Entre os dois eu partiria para JPA2 mesmo, já que a partir dele é possível também acessar os recursos do hibernate.

Em relação à JSF, vai muito da estrutura de tela do projeto. Quando é necessário telas mais artesanais, com muitos detalhes o uso de JSF é muito custoso. Não significa que não é possível fazer, mas que o custo é bem alto.

Quando ao banco eu particia memso para postgresql ou oracle dependendo do volume de dados neste banco.

Em relação aos frameworks, qual o nível de conhecimento da equipe?

Comento isso porque o mau uso de frameworks de persistência acabam gerando muitos problemas de performance na aplicação. Não use apenas a estrutura de mapeamento padrão do JPA/Hibernate. Vá mais a fundo na API, principalmente para a realização de consultas na base.

Ao meu ver para as consultas mais pesadas cabe a análise apurada usando o hibernate statistics e análise de plano de execução das queries geradas pelo JPA/Hibernate.

Caso já tenha código construído recomento também o uso de profiles no sentido de identificar gargalos na aplicação antes dos testes de requisitos não funcionais.

Sei que demorei para responder, mas com trabalho e pós ao mesmo tempo tá difícil participar do forum com frequencia.

Boa sorte.

Algumas opiniões minhas:

1. Não sei como o JSF 2.0 funciona com respeito ao armazenamento do estado dos componentes e se os frameworks como Richfaces estão mais eficientes agora, mas trabalhei alguns anos atrás em projetos usando JSF 1.X e tive problemas com essas duas coisas… Se eu armazenava o estados dos componentes no servidor, ele ficava muito carregado, se eu armazenava os estados dos componentes num campo hidden codificado do formulário era um volume razoável a mais de dados trafegados. E o código gerado pelos componentes visuais eram muito grandes e ineficientes, ficava muito difícil aplicar técnicas de otimização de front-end. Se for um sistema usado na intranet o impacto é um pouco menor. Eu recomendo usar algum framework mais leve e usar jQuery/jQuery UI. Dificilmente você vai sentir falta de algum componente do Richfaces/Primefaces (ou qualquer outro framework de componentes visuais do JSF).

2. Pra questões de performance, acho que a discussão JPA X Hibernate não faz muito sentido, acho que a diferença maior não esta em qual ferramenta ORM você usa e sim como você usa essas ferramentas. Cuidado com problemas como select N + 1.

3. Cuidado com dicas como “use EJB”. EJB não faz sua aplicação ficar magicamente mais escalavel e existem diversas formas talvez até mais eficientes de deixar usa aplicação mais escalavel - taí os milhares de sites que usam PHP, Rails, Python ou usam Java sem EJB pra provar isso. O que você precisa é saber usar uma ferramenta de load balance e ter certeza que os recursos que sua aplicação usa podem ser usados num ambiente distribuido.

4. Uma coisa que sempre ajuda é usar uma ferramenta que permite processamento em paralelo, como JMS. Se um processo é pesado e pode ser feito em background, faça ele ser executado fora da request http, em outra thread.

No fim das contas o que vai determinar se a sua aplicação vai atender a demanda ou não é a sua arquitetura e sua infra-estrutura e não especificamente as ferramentas que você vai usar. Também é importante identificar quais são os gargalos e os pontos críticos da sua aplicação - exemplo, não adianta ficar otimizado as queries do Hibernate se o problema que você esta tendo é lidar com arquivos muito grandes.

Uma coisa importante: muito cuidado com NoSQL! Eu já usei e deu muito certo, mas geralmente ele tem usos bem específicos - não usaria NoSQL para fazer uma app que controla a conta corrente por exemplo.

E geralmente ele é mais difícil de gerenciar na parte de infra-estrutura. Na verdade não mais difícil, mas o pessoal esta mais acostumado a lidar com banco de dados tradicionais.

No cenário apresentado acima, eu optaria por um baixo acoplamento:

Camada de Negócios:
CDI
WebService RestFul

Visão Modular:
Web
Html (JQuery)
Intranet/Desktop
JavaFX

Banco de dados:
Oracle / SQLServer

AppServer:
JBoss 7

felipef:

icarocd

Pq? O que não consigo fazer com JSF?

Não é nem q não consiga fazer,o problema é que um pouco mais dificil de customizar os componentes visuais(.js,.css etc)

raf4ever:

felipef:

icarocd

Pq? O que não consigo fazer com JSF?

Não é nem q não consiga fazer,o problema é que um pouco mais dificil de customizar os componentes visuais(.js,.css etc)

Acredite, aprenda a usar GWT. Se vc estiver em um projeto realmente grande, nunca mais vai querer usar outra coisa …

http://www.guj.com.br/java/282623-gwt-google-web-toolkit-alguem-usa--experiencias-

andre_salvati:

raf4ever:

felipef:

icarocd

Pq? O que não consigo fazer com JSF?

Não é nem q não consiga fazer,o problema é que um pouco mais dificil de customizar os componentes visuais(.js,.css etc)

Acredite, aprenda a usar GWT. Se vc estiver em um projeto realmente grande, nunca mais vai querer usar outra coisa …

http://www.guj.com.br/java/282623-gwt-google-web-toolkit-alguem-usa--experiencias-

Hehe,o primeiro comentário não foi nada animador

Vc desistiu logo no primeiro e com um cara que nunca trabalhou com GWT?!!?

Seja persistente, leia até o final…

Algumas dicas:

• JSF não foi feito para quem busca performance. Mas é uma ideia interessante para economizar tempo de desenvolvimento. Uma página aberta como por exemplo a home do submarino, jaais deverá ser feita em jsf, já a área logada, atenderia sem problema algum.

• NoSQL eu não sugiro, a manutenção ainda é obscura e poucas pessoas conhecem a fundo, para tratar bugs. O banco de dados SQL Server é legalzinho, mas já que é pra pagar, tente optar por um DB2 ou Oracle. Se não querem pagar, MySQL com certeza.

• Quanto a concorrência, não tem problema algum se 1 ou 1.000 pessoas estão vendo o mesmo registro, existe cache no JPA. O problema ocorre se desses 1.000 somente um poderá ver o registro. Daí você precisa de uma estratégia de concorrência (JPA também trata disso)

• Servidor recomendo fortemente JBoss AS 7 (no modo domain), e em conjunto você pode configurar o mod_cluster no apache para criar um ambiente clusterizado com replicação de sessão do usuário.

Giulliano:

Algumas dicas:

• JSF não foi feito para quem busca performance. Mas é uma ideia interessante para economizar tempo de desenvolvimento. Uma página aberta como por exemplo a home do submarino, jaais deverá ser feita em jsf, já a área logada, atenderia sem problema algum.

• NoSQL eu não sugiro, a manutenção ainda é obscura e poucas pessoas conhecem a fundo, para tratar bugs. O banco de dados SQL Server é legalzinho, mas já que é pra pagar, tente optar por um DB2 ou Oracle. Se não querem pagar, MySQL com certeza.

• Quanto a concorrência, não tem problema algum se 1 ou 1.000 pessoas estão vendo o mesmo registro, existe cache no JPA. O problema ocorre se desses 1.000 somente um poderá ver o registro. Daí você precisa de uma estratégia de concorrência (JPA também trata disso)

• Servidor recomendo fortemente JBoss AS 7 (no modo domain), e em conjunto você pode configurar o mod_cluster no apache para criar um ambiente clusterizado com replicação de sessão do usuário.

Concordo com relação a JSF.

Discordo com relação a NoSQL. Qualquer empresa que esteja pensando em criar serviços sérios e escaláveis na Web deve considerar NoSQL. Já opero a mais de 4 meses com o BigTable (App Engine) com uma média de 6 reqs/segundo e ainda não tive indisponibilidade de banco. Não preciso me preocupar com manutenção de banco e ela é “obscura” mesmo, mas tenho certeza que o pessoal de infra do Google cuida pra mim…