Olá pessoal,

Sou de Recife e sou novo por aqui. Estou tocando um projeto e estou me deparando com algumas duvidas de projeto, como por exemplo até que ponto a utilização do padrão facade é vantajoso no ponto de vista de performance de uma aplicação Java Web.
A minha preocupação são os vários acessos simultâneos a minha aplicação acabar gerando um overhead no acesso ao facade, visto que é um singleton.
Dai lanço a discussão...: é melhor utilizar facade (singleton)? é melhor utilizar um facade diferenciado, isto é, uma classe normal que é instanciada e que nao é singleton? é melhor não utilizar facade de forma alguma?

bem... desde já desculpas pela minha mera ignorância... :D
e obrigado a todos que queiram participar desta discussão

Exibições: 27

Respostas a este tópico

Danilo,

Apesar da discussão parecer apenas com detalhes de implementação de código, o seu problema vai muito mais além e requer uma análise muito mais cética. Vou tentar lhe mostrar uma direção ...

Existem dois tipos de escalabilidade: Vertical e Horizontal. Segue os detalhes de cada uma delas:

- Vertical: Suportar o crescimento de usuários considerando apenas um computador (node) que irá suportar o processamento de um sistema, e pra atender o crescimento, inserir mais recursos de hardware como CPU e RAM.
- Horizontal: Ao invés de um unico computador, considerar várias máquinas colaborando pra suportar o crescimento do acesso. A cada pico de crescimento, mais máquinas são inseridas, com a mesma configuração de hardware.

Dito isso, a decisão que você deve tomar não é se você vai usar façades singletons ou não (detalhes de implementação), e sim, que tipo de escalabilidade seu sistema precisa. Esta é uma decisão que envolve uma análise profunda no tipo de sistema, na expectativa deste sistema quando a uso, ao seu tempo de aposentadoria, como recursos são aprovisionados, etc.

Digamos que você opte por escalabilidade horizontal (+ máquinas, recursos homogêneos). Seria muito interessante a adoção de uma estratégia Web Centric + EJB Centric, e fazer com que suas fachadas sejam EJB's Stateless, e não, eles não seria singletons. Através do recurso de pooling, o cenário de instânciação de cópias de sua fachada no JVM estaria num estado "controlado", pois poucas instâncias revezariam-se para atender a vários threads (padrão Flyweith). Além disso, os ciclos de garbage collection do EJB contêiner seria menores, devido ao fato de que as instâncias de um pool são referências opacas (Weak References) e menos suscetíveis a coleta.

Outro ponto importante no uso do EJB Centric, é o recurso provido pelas interfaces remotas. Interfaces remotas criam um "problema" de precisar de processamento de serialização e marshaling devido a transferência de dados entre JVM's diferentes, porém, através da sua transparência de localização (sem afinidade de endereços de servidores) você pode usar máquinas em cluster para sustentar suas fachadas, e até mesmo usar algoritmos eficientes de balanceamento de carga de tais máquinas (Random, Round Robin, etc). Além disso, estou falando que sua solução teria um poder de resiliência bem maior, devido ao uso de máquinas tolerantes sem afinidade com a camada cliente. Enfim, em termos de escalabilidade, considero uma opção interessante.

Agora considere o uso de escalabilidade vertical. fachadas singleton pra mim não parecem interessantes, pois apesar de usarem menos recurso de memória alocada, elas geram problemas de concorrência. Vários threads acessando uma unica instância significa enfileiramento de threads, e o tempo de resposta da sua aplicação poderia degradar. Caso você opte por usar fachadas não singleton (também conhecidas como Prototypes), você resolveria o problema de concorrência e enfileiramento de threads, porém compraria o problema de alocação de memória. Com o tempo, e o crescimento, você facilmente chegaria a um "No Memory Available".

Mas, se a escalabilidade vertical ainda lhe for interessante, sugiro fazer um teste de stress em quanto de recursos são alocados quando uma massa de requisições são feitas para seu sistema, e considere o uso de uma infra de hardware que acomode este pico de acesso, mas colocando uma margem (gordura) neste hardware para um possivel crescimento. E claro, deixar claro que pra suportar outro crescimento, o aumento da configuração de hardware será imperativo. Considere também que alguns sistemas operacionais (principalmente os de 32 bits) possuem restrições quanto a memória e CPU, portanto chega uma hora, que mesmo que você tenha 80 GB de RAM na máquina, ele só reconhecerá 16 GB.

Se pude ser claro, eu recomendo que você invista em escalabilidade horizontal ;)

Cordialmente,

Ricardo Ferreira
http://architecture-journal.blogspot.com

RSS

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço