Loading ...
Sorry, an error occurred while loading the content.

Re: RES: Re: [riojug] Lentidão

Expand Messages
  • wardog1
    Ve se isso te ajuda, tambem. http://www.javaworld.com/gomail.cgi?id=658654
    Message 1 of 3 , Mar 2, 2005
    • 0 Attachment
      Ve se isso te ajuda, tambem.

      http://www.javaworld.com/gomail.cgi?id=658654


      On Tue, 1 Mar 2005 17:23:05 -0300, Timothy Ryan High <THigh@...> wrote:
      > Alexandre,
      > Gostei da sua lista! Esta lista fala mais de soluções de "hardware", então
      > gostaria de acrescentar mais alguns "pitfalls" e soluções para a
      > arquitetura
      > e codificação da aplicação:
      >
      > * Usar uma ferramenta de "profiling" para identificar pontos na aplicação
      > de
      > baixo desempenho
      > * Considera em usar uma ferramenta para fazer cacheamento de objetos comuns
      > e principalmente de leitura
      >
      > Para aplicações com JDBC:
      > * Ver a metodologia de gerenciar as conexões do banco (tá usando pool? tá
      > reutilizando as conexões na mesma request, ou tá utilizando várias conexões
      > ao mesmo tempo? tá fechando as conexões direitinho?)
      > * Ver a utilização de transações (procura limitar o tempo que uma transação
      > fica aberta sem dar um commit)
      > * Executar um profiling nas queries SQL para verificar o desempenho de cada
      > um
      > * Ver as configurações do banco (indexação, configuração de locks,
      > utilização dos tablespaces, etc.)
      >
      > Para aplicações com mapeamento O/R:
      > * Ler a documentação da ferramenta para ver as opções de configuração
      > * Ver as configurações do banco (indexação, configuração de locks,
      > utilização dos tablespaces, etc.)
      >
      > Para aplicações EJB:
      > * Usar o padrão VO/DTO (Data Transfer Object) para reduzir trâfego na rede
      > * Usar interfaces locais aonde for possível
      > * Estudar as configurações de transação e de segurança para configurar o
      > mínimo necessário e reduzir conflitos
      > * Ler a documentação do servidor de aplicação para ver as opções de
      > otimização
      > * Ver as configurações do banco (indexação, configuração de locks,
      > utilização dos tablespaces, etc.)
      >
      > Tem tantas possibilidades para a melhoria do desempenho de uma aplicação
      > que
      > não dá para lista (nem adivinhar todas). Uma aplicação deve procurar:
      > * Limitar a utilização desnecessária de memória (porém lembre-se de que
      > memória é o lugar mais rápido de se acessar algum dado ou objeto)
      > * Limitar o consumo de recursos remotos (conexões com banco ou outros
      > sistemas)
      > * Reduzir o trâfego na rede
      > * Reduzir concorrência para objetos e recursos compartilhados
      > (sincronização, lock em registros no banco de dados, etc.)
      > * Liberar recursos assim que não serão mais utilizados (dar commit na
      > transação, fechar a conexão com o banco, tirar objetos da sessão quando não
      > são mais necessários)
      >
      > Mas a aplicação não pode fazer tudo... tem que ter hardware suficiente para
      > o nível de utilização da sua aplicação.
      >
      > abs,
      > tim.
      >
      >
      > -----Mensagem original-----
      > De: Alexandre Brasil [mailto:alexandre.brasil@...]
      > Enviada em: terça-feira, 1 de março de 2005 16:52
      > Para: riojug@yahoogroups.com
      > Assunto: Re: Re: [riojug] Lentidão
      >
      >
      >
      > Vivian,
      >
      > Infelizmente, a tendência de aplicações com muitos usuários
      > concorrentes é a lentidão. Existem algumas opções para melhorar o
      > desempenho, aumentar a capacidade de atendimento simultâneo e retardar
      > a lentidão do sistema, mas vão depender de uma análise mas detalhada
      > do funcionamento e arquitetura do seu sistema. Exemplos:
      >
      > * Usar um cluster de servidores WEB
      > * Usar um cluster de servidores de aplicação
      > * Utilizar servidores web instalados dentro do servidor de aplicação,
      > e utilizar interfaces locais nas chamadas a EJBs pelos servlets
      > (quando estiver trabalhando com EJBs)
      > * Aumentar a largura da banda de rede
      > * Trocar os processadores dos servidores por outros mais velozes
      > * Trocar os discos rígidos dos servidores por outros mais velozes
      > * Colocar mais memória nos servidores, para evitar/minimizar o uso de swap
      > * Configurar o uso de um cache (distribuído ou local) nos seus componentes
      > * Melhorar o equipamento de seu banco de dados
      > * Trocar o Banco de dados por outro mais rápido
      > * Criar um cluster de banco de dados replicados ou particionados
      > (procure pro CJBDC e RAIDb)
      > * Reescrever sua aplicação caso a arquitetura tenha sido mal-projetada
      > e interfira no desempenho
      >
      > É possível que qualquer das alternativas acima melhore o desempenho de
      > sua aplicação, mas também é possível que nenhuma delas surta efeito.
      > Como eu disse antes, o "tunning" de uma aplicação depende de uma
      > análise meticulosa da mesma em funcionamento.
      >
      > []'s
      > Alexandre Brasil
      >
      > On Tue, 1 Mar 2005 12:35:24 -0300, vivian. kb <vivian.kb@...> wrote:
      > > Olá Phillip,
      > >
      > > Então, em um sistema HomeBanking, onde temos vários sessões abertas e
      > > transações sendo efetuadas ao mesmo tempo, causaria então uma lentidão no
      > > sistema. O que poderia ser feito para tentar resolver esse tipo de
      > lentidão
      > > na prórpia aplicação web. Seria alguma coisa referente a threads ou
      > acesso
      > > ao servidor? Gostaria de saber como posso otimizar um sistema para que
      > não
      > > exista problemas de lentidão devido ao grande nº de operações e acesso ao
      > > sistema.
      > >
      > > Obrigada,
      > >
      > > Vivian Ferreira
      > >
      > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      > > Rio Java Users Group www.riojug.org
      > > E-mail dos Moderadores riojug-owner@yahoogroups.com
      > >
      > > Patrocínio: SENAC-Rio, Quality Software, Locaweb
      > > Apoio: Java Magazine, SQL Magazine
      > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      > > Participe também das outras listas do RioJUG:
      > > SCJP (groups.yahoo.com/group/scjp_riojug)
      > > SCWCD (groups.yahoo.com/group/scwcd_riojug)
      > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
      >
      >
      > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      > Rio Java Users Group www.riojug.org
      > E-mail dos Moderadores riojug-owner@yahoogroups.com
      >
      > Patrocínio: SENAC-Rio, Quality Software, Locaweb
      > Apoio: Java Magazine, SQL Magazine
      > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      > Participe também das outras listas do RioJUG:
      > SCJP (groups.yahoo.com/group/scjp_riojug)
      > SCWCD (groups.yahoo.com/group/scwcd_riojug)
      > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
      > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      > Rio Java Users Group www.riojug.org
      > E-mail dos Moderadores riojug-owner@yahoogroups.com
      >
      > Patrocínio: SENAC-Rio, Quality Software, Locaweb
      > Apoio: Java Magazine, SQL Magazine
      > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      > Participe também das outras listas do RioJUG:
      > SCJP (groups.yahoo.com/group/scjp_riojug)
      > SCWCD (groups.yahoo.com/group/scwcd_riojug)
      > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      >
      >
      >
      > Yahoo! Groups Sponsor
      >
      > ADVERTISEMENT
      >
      >
      > ________________________________
      > Yahoo! Groups Links
      >
      > To visit your group on the web, go to:
      > http://groups.yahoo.com/group/riojug/
      >
      > To unsubscribe from this group, send an email to:
      > riojug-unsubscribe@yahoogroups.com
      >
      > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    • Geraldo Xexeo
      Que me perdoem os envolvidos... Nunca vi uma pergunta tão mal feita ser tão bem respondida. Para descobrir uma solução para a lentidão de uma aplicação
      Message 2 of 3 , Mar 4, 2005
      • 0 Attachment
        Que me perdoem os envolvidos...

        Nunca vi uma pergunta tão mal feita ser tão bem respondida.

        Para descobrir uma solução para a lentidão de uma aplicação é necessário
        analisar o porque dessa lentidão, se ela realmente existe (já que
        lentidão é uma observação do usuário).

        Como deve ser uma arquitetura multi camadas, a primeira análise deve ser
        em busca de que camada está atuando como gargalo. Algumas vezes isso
        pode ser visto simplesmente observando o desempenho do sistema, vendo
        que processos ocupam mais memória e CPU. Outras ferramentas podem ajudar
        você a uma análise melhor.

        Exemplo: Uma aplicação que eu usava era muuuito lenta em um servidor
        n-camadas. Motivo: servidor de banco de dados atuando na sua capacidade
        máxima e botando a língua de fora. Solução desse caso: upgrade de hardware.

        Descoberto a localização da lentidão, é necessário usar então
        ferramentas especializadas para determinar o motivo.

        Em alguns casos, porém, uma camada pode estar no gargalo porque outra
        camada não está implementada de maneira ótima (não necessariamente ruim,
        porém muito provavelmente ingênua).

        Exemplo (aconteceu comigo): Aplicação muito lenta. Servidor de banco de
        dados botando a língua de fora. Identificação do problema: excesso de
        consultas para realizar operações simples (decorrência do JBoss).
        Algumas transações geravam 25.000 consultas, sendo que incluiam updates
        de dados que não foram mudados!!!!
        Ação: estudo da arquitetura do JBoss na época, mudança da forma de uso
        de cache do JBoss, otimizações internas no código para realizar o mínimo
        de updates, inclusive zero se necessário. Aumentar a granularidade dos
        objetos na consulta. Anotar a lição aprendida com o Jboss. Resultado:
        radical diminuição no número de consultas, aplicação passou de poucas
        horas para realizar um código para menos de 10 (2 a 5 normalmente) minutos.
        Obs: um usuário ainda achou 2 a 5 minutos lento, pois não tinha noção
        do trabalho computacional que estava pedindo.
        Ações: realização de cálculos antecipados. Materialização de relatórios
        (só são realizados na primeira vez que são pedidos, até que os dados
        sejam mudados). Implantação de um cache para dados na arquitetura.
        Resultado: diminuição para menos de 15 segundos na segunda chamada dos
        relatórios, em uma rede muito lenta.
        Usuário feliz.

        Como você vê, a solução pode ser simples ou complicada, longa ou curta.

        Também tem o caso da Bolsa de NY, que usa JBoss. Eles acabaram montando
        dois clusters diferentes, um de informação de cotações, com dezenas de
        máquinas, cache e delay de alguns segundos, e outro de venda, com poucas
        máquinas e delay zero. A questão é que o cluster grande, por causa do
        cache, podia atender muuuito mais rapidamente as consultas. Esse caso
        foi apresentado por Mark Fleury quando esteve no Rio.
      Your message has been successfully submitted and would be delivered to recipients shortly.