Relação entre quantidade de camadas e performance

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.

Colega, entendo que a sua dúvida é academica. Só tome cuidado pra não cair na armadilha da otimização prematura.
Da uma lida: http://c2.com/cgi/wiki?PrematureOptimization

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.

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.

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

Eai pessoal,

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

Ah sim, com certeza… mas, dependendo do quão crítica for sua aplicação o problema também ocorrerá em Java.

Um ponto que vale a pena lembrar é que quanto mais camadas mais complexo vai ficar seu programa e mais complicada a manutenção…

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.

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í…

Nada pode ser criticado por seu mau uso

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.

Ferryman:

Eai pessoal,

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

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á.

[]'s

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 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.

eduveks:

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.

Se você entendeu isso, acho que me expressei mal.

Certamente escalar horizontalmente é bom… O problema que tentei expressar foi ter seus objetos distribuidos… algo como um modulo do sistema em cada servidor, ou então ter a camada de view em um servidor e a camada de negócio em outro etc… isso não vai ajudar com performance, pelo contrario, isso vai ferrar sua performance, ja que pra qualquer funcionalidade irá realizar chamadas remotas em outras jvms.

Este cenário realmente não é bom pra performace… agora você pode ter todo seu projeto deployado em varios servidores em um cluster para conseguir load-balance e até fail-over se for necessário.

[]s

camadas é um conceito… basicamente são 3 (não conheço nenhum outro conceito de mais de 3 camadas…) diante destas 3 camadas vc pode ter varias chamadas varios patterns pode ter uma view que chama um facade que chama um delegate que chama um AS que chama um DAO que faz acesso ao banco…
isto continua sendo 3 camadas mas com varias delegações… mas compensa muito fazer isto? não… até certo ponto esta divisão é boa… mas tenque achar um ponto que a performace e a manutenção sejam adequadas… as camadas devem ser sempre organizada em um ponto que cada uma tenha uma determinada função especifica… e não se pode fragmentar uma função especifica em mais camadas e em colocar mais funçoes para um unica camada… vide o modelo OSI ele é exatamente isto… isto falando de camadas logicas…
porem em camadas fisicas depende muito… tem o custo da velocidade da rede, ruidos e coisas assim… se o sistema for muito grande receber muitas requisições ter muitos acessos é algo que compensa e que ganhara muita performace… mas agora se o sistema for de um porte pequeno com poucas requisições… um sistema de uma pequena/media empresa que so os funcionarios acessem… não a pq dividir em camadas fisicas pois os outros fatores como velocidade de cominicação, da rede, ruidos, etc… irão piorar a performace…

aqui pro cliente que trabalho uma empresa gigantesca com varias filiais no pais… o sistema aqui tem somente o balanceamento de carga de requisições em 2 servidores… e isto funciona bem poraqui…

E lembrando que isso não quer dizer nada em geral. Por mais disco/memória/processador que um nó tenha existem diversos casos onde particionar o trabalho entre máquinas diversas é estupidamente mais rápido. Cada caso é um caso e como eu sempre digo aqui a princial atribuição de um arquiteto é avaliar estes casos -e por isso que arquitetura de referência é besteira.

Dividir sua aplicação em camadas pode te trazer diversos benefícios entre eles manutenção, reúso de código, escalabilidade e blá blá blá.
Mas para vc usufruir dessas vantagens o produto deve ser bem projetado visando alta coesão e baixo acoplamento. Para evitar camadas algumas “vazias” e outras “inchadas”… Como aconteceu tanto no OSI qto no TCP
Enquanto a performance se vc concordar comigo que até comunicações de rede, que geralmente procuram confiabilidade e velocidade, são construidas em cima de uma pilha de protocolos pq com software não pode ser igual.