Pessoal, estou com uma dúvida acadêmica, não tenho um exemplo real pra dar mas enfim…
Qual a relação entre a quantidade de camada e a performance da aplicação?
Por exemplo, desde a apresentação até a persistência tenho inumeras camadas, apesar de poder distribuir as camada em várias máquinas, a quantidade excessiva de camadas pode afetar negativamente a performance de uma aplicação?
E se eu não puder distribuir as camadas, ou seja, toda minha aplicação estiver em uma só máquina, como a quantidade de camadas irá afetar a performance da aplicação e quão significativa seria essa diferença?
Ficaria grato tb se pudessem me passar algum link sobre o assunto ou diretrizes sobre o que procurar
Cara, normalmente se trabalha com 3 camadas (view, camada de negocio e acesso a banco). Normalmente o custo de performance em ter essas camadas é irrelevante pois é apenas uma chamada de função a mais e vale muito mais a pena você organizar seu código de forma bem distribuída do que arriscar fazer um código mal estruturado que executará em apenas uma camada. Colocar tudo em uma camada gera problemas como péssima capacidade de manutenção, que pode impactar em má performance em alguns casos já que quem vai dar manutenção no sistema irá normalmente dar uma volta maior para fazer uma alteração já que ele é que não vai querer mecher naquele "espaguete" de código.
Ok, os benefícios de se trabalhar com camadas estão bem entendidos, a questão é, quais são os problemas (se é que existem) de se distribuir demasiadamente o código, principalmente na situação mencionada no trecho que digo
Tu vai usar maior quantidade de processamento para fazer os acessos aos métodos e também haverá degradação da memória devido à pilha de execução do sistema. Também haverá problemas com memória pois cada camada que você usar vai ser um novo objeto e objetos ocupam memória quando são carregados. Dadas as capacidades de hardware atuais esses valores NORMALMENTE são irrelevantes, a menos que haja uma falta total de bom senso ao criar camadas, mas realmente é dificil de fazer isso acontecer.
Uma coisa importante é que você deve planejar suas camadas de forma que o sistema possa ser distribuído entre várias maquinas a qualquer momento sem que haja mudanças no sistema que não sejam a adição de middleware para acesso remoto a outras JVMs, controle de transações distribuídas (commit em 2 tempos), e outras pendências que derivam desta distribuição.
Acho que todos concordam que isto é uma questão quase irrelevante quando de trabalha com Java. Talvez isto represente problemas em outras linguagens como PHP, mas mesmo assim é possível fazer um MVC decente…
A quantidade excessiva de camadas pode sim gerar problemas de performance.
E não tem nada a ver o fato de ser ou não Java.
Tudo depende, claro, do perfil de sua aplicação e da forma como as camadas são organizadas. Isso é mais sentido em aplicações de tempo real, onde atrasos são críticos, especialmente aquelas que devem ter um tempo de resposta muito curto. Para aplicações comerciais, isso é pouco relevante.
Cada camada adiciona seu overhead de processamento. Um programa com camadas demais também se torna complexo, e muitas vezes as camadas ficam vazias ou perdem seu foco, adicionando processamento inútil.
Existem até exemplos históricos disso, como o caso OSI em relação ao TCP. As implementações OSI iniciais ficavam complexas e pesadas. Havia até implementações redundantes nas camadas 2 e 4, por exemplo.
Mas é claro. É importante dividir um sistema em camadas e, quando bem organizadas, o seu overhead mais do que é pago pela funcionalidade que ela presta e pela facilidade de manutenção. Para uma aplicação onde os tempos não são críticos, é difícil que a diferença de performance chegue a ser perceptível. Por isso, o alerta do colega é válido, abrir mão de uma arquitetura mais elegante prematuramente pode ser mais prejudicial do que o ganho de performance que ocorreu, mas ninguém percebeu.
[quote=ViniGodoy]A quantidade excessiva de camadas pode sim gerar problemas de performance.
E não tem nada a ver o fato de ser ou não Java.[/quote]
Gutmans, Bakken & Rethans em seu já famoso livro “PHP 5: Programação Poderosa” descrevem esta questão deixando claro que, como eles mesmos dizem, “PHP não é Java”, ou seja, os mecanismos de chamadas a métodos da primeira não são tão eficientes quanto a segunda e que, por conseguinte, aplicações com múltiplas camadas em PHP podem apresentar um desempenho BEM abaixo se comparado a outras linguagens. Por isto que PHP não possui classes como “Collections” et caetera.
Diferentes linguagens podem contemplar ou desmerecer diferentes abordabens de desenvolvimento. E isto é um fato que precisa ser observado.
Aquele abraço!
San
Em java a utilização de camadas lógicas para organizar o sistema tem impacto insignificante em desempenho… O maior problema é com camadas físicas (maquinas diferentes rodando partes diferentes do sistema). Neste segundo caso a quantidade de chamadas remotas é grande, carregam a rede e são muito mais demoradas que uma chamada a um processo local.
Epa! Há controvérsias. Um dos objetivos de dividir uma aplicação em camadas é justamente facilitar sua manutenção, agrupando componentes que possuem responsabilidades em comum ( alta coesão ) e diminuindo a dependência entre esses grupos ( baixo acoplamento ). Essa preocupação permite que partes isoladas de um sistema possam ser modificadas sem causar maiores impactos em outras.
Comforme seu sistema cresce, adicionar camadas facilita a manutenção, ao contrário do que você disse. Separação em camadas é uma técnica que surgiu exatamente pra fazer o contrário do que você acabou de dizer.
Comforme seu sistema cresce, adicionar camadas facilita a manutenção, ao contrário do que você disse. Separação em camadas é uma técnica que surgiu exatamente pra fazer o contrário do que você acabou de dizer.[/quote]
Tudo depende da quantidade de camadas. E também delas terem um propósito bem definido. O que ele falou é válido para um sistema com camadas demais, como aconteceu com a pilha OSI. Camadas em demasia ou sem um objetivo claro prejudica o sistema, torna ele mais complexo e menos coeso, e são um erro grave de projeto.
Puxa, acho que me expliquei mal…
Claro que separar em camadas facilita a manutenção!
O problema é quando o cara começa a separar em MUITAS camadas, tornando a granularidade muito fina… Pelo menos foi isso que eu entendi da pessoa falar “quantidade excessiva de camadas”!
Foi malz aí…
Não existe relação entre número de Camadas de performance, especialmente porque Camada é um conceito lógico, a linguaem em si não tem a menor ideia se você está chamado um método na mesma camada ou em outra, para ela são dois objetos se comunicando.
Em java a utilização de camadas lógicas para organizar o sistema tem impacto insignificante em desempenho… O maior problema é com camadas físicas (maquinas diferentes rodando partes diferentes do sistema). Neste segundo caso a quantidade de chamadas remotas é grande, carregam a rede e são muito mais demoradas que uma chamada a um processo local.
[]s
Ferry[/quote]
Isto não é bem assim, separar em vários servidores tem muitas vantagens e maior performance, basicamente vc pode ter balanceamento em cada camada, e a velocidade da rede, congestionar a rede? 1GB/s não chega? E se as camadas tiverem ligadas em redes fechadas?
O cenário para uma aplicação de grande porte é este, alguns servidores para cada camada, a quantidade/qualidade dos servidores depende da carga, com balanceamento em todas as camadas.
Este cenário é muito superior a ter tudo em uma máquina só, mesmo q seja uma super máquina, além da garantia de disponibilidade do serviço, muito flexível para contornar problema nas máquinas, além de poder fazer manutenção num servidor e deixar o outro trabalhando e vice-versa.
Este assunto, na minha opinião, é mais um daqueles casos do tipo “depende”.
Teóricamente se colocar todo o código em um método apenas (o macarrão) será mais rápido do que estruturar a coisa toda em algumas classes e métodos, porque com um único método o código poderá ficar em um mesmo seguimento de código (se não for muito grande) e o micropocessador não terá que calcular (no caso do intel) onde está a próxima parte do código, ao passo que se estiver em vários métodos haverá um tempo gasto pelo micropocessador para encontrar as outras partes do código. Mas pergunto lhes: É bacana fazer isso? Eu acho que não.
Sempre há um preço a se pagar por aquilo que vc quer e não estou falando só de dinheiro rsrsrsrs.
Camadas podem impactar em desempenho? Na minha opinião sim, mas é ai que entra a inteligencia do ser humano que irá trabalhar para dizer como desenvolver um sistema organizado, elegante, com alta disponibilidade, fácil de utilizar, bonito (rsrsr), RÁPIDO e etc…
Nas redes existem componentes bastante inteligentes…no primeiro acesso vc pode notar uma pequena demora mas quando vc acessa novamente é quase instantaneo o sistema como um todo se prepara pra lhe atender rapidamente, faça um teste na rede onde vc trabalha e verá.
[quote]Isto não é bem assim, separar em vários servidores tem muitas vantagens e maior performance, basicamente vc pode ter balanceamento em cada camada, e a velocidade da rede, congestionar a rede? 1GB/s não chega? E se as camadas tiverem ligadas em redes fechadas?
O cenário para uma aplicação de grande porte é este, alguns servidores para cada camada, a quantidade/qualidade dos servidores depende da carga, com balanceamento em todas as camadas.
Este cenário é muito superior a ter tudo em uma máquina só, mesmo q seja uma super máquina, além da garantia de disponibilidade do serviço, muito flexível para contornar problema nas máquinas, além de poder fazer manutenção num servidor e deixar o outro trabalhando e vice-versa.[/quote]
Este cenário é igual a ter uma camada apenas com balanceamento de carga e clusterização. Realmente não vejo ganho no que você disse, apenas em casos que alguns serviços serão separados, porém isto não tem nada a ver com camada.
Lembrando que em uma “super maquina” o processamento é todo feito em memoria/cpu/disco, que é muito mais rápido que qualquer rede existente.
