Quanto de Memória Ram em um servidor para pequenas aplicações?
04/03/2012 18:32
1
Uma aplicação Grails com 3 classes de domínio poder rodar em um servidor com apenas 128 MB de Ram?
Tags: servidor 128 ram memória


0
Qual a versão do GRails ??? Qual o Sistema Operacional que você vai usar ???

Sua RAM é um impeditivo ??? A máquina vai ficar dedicada a sua aplicação ???

Eu acho muito pouco. Estou usando o GRails 2.0.0 em um Windows XP com 6 Domains... Dando o run-app só pra criar o banco já vai 137 Mb de memória em stand by, chegando a um Pico de 350 Mb quando está subindo a App...

Lembre que quando uma App GRails está subindo, fora seus domaisn comuns, muitas outras coisas estão rodando por trás para construir sua estrutura, nada acontece com mágica.

Meu conselho é no mínimo 512 Mb dedicado a VM.

PS: Ainda não verifiquei o comportamento da App no Linux.

Abs [] e sucesso na implementação.
05/03/2012 15:07


0
O Grails Brasil funciona bem: e o servidor tem 600 Mb de RAM.


0
Kiko, esponha um pouco mais sobre o que usas no GRailsBrasil...

Versão do GRails, Banco de Dados, Sistema Operacional, etc...

Abs []
05/03/2012 18:12


0
O Grails Brasil roda numa VM?
05/03/2012 18:48


2
Bom: o Grails Brasil que todo mundo usa é na realidade um belo laboratório de pesquisa. Um dos objetivos por trás do projeto foi criar uma aplicação Grails EXTREMAMENTE otimizada que consumisse o mínimo de memória possível (repararam como as buscas e o acesso ao site é rápido?).

Então, desde o início do projeto, tomei algumas decisões que me ajudaram bastante:

1) Toda busca é feita pelo Lucene. Raríssimas vezes toco no MySQL

2) Na modelagem do domínio, não há relacionamentos bidirecionais. Adotei a prática do "pai inconsequente". Com isto, toda busca no banco de dados é muito mais rápida e não preciso me preocupar com lazy loading de domínios complexos, etc.

3) BOA parte do processamento é assíncrono. Os usuários nem percebem, mas quando, por exemplo, uma notícia é publicada ou um e-mail enviado, este procedimento não é feito na hora. Assim economizo acesso ao banco de dados, serviços de mensageria, etc.

4) O banco de dados é ultra enxuto. E como o acesso ao banco é raro (90% do acesso ao Grails Brasil é para buscas apenas), e o Lucene faz o trabalho de indexação, não há um consumo bruto de memória.

5) O conteúdo estático não está no mesmo servidor que meu war

6) E a maior parte das otimizações do YSlow foram aplicadas também

7) Eu tenho um tratamento "especial" dado para os bots. Na primeira versão do Grails Brasil, estes destruiam o meu dia. Na nova, não fazem cócegas (um dia explico como fiz isto). Com isto consegui duas coisas legais: ACABEI com o SPAM de vez e reduzi o consumo de recursos do sistema bastante (40 a 60% do tráfego vinha de BOTS na primeira versão)

8) Sessões do usuário: são mínimas

9) Plugins que uso: jQuery (e só o jQuery que me lembro neste momento)

10) Tem um pouco de "mágica" por trás também :)

Com isto, consegui otimizar bastante o site, de tal modo que no meu setup atual, tenho na mesma imagem do AWS tanto o MySQL quanto o Tomcat executando sem problema. O Tomcat, inclusive, está configurado para usar apenas (pasmem alguns) 256 Mb de RAM.

A imagem que uso tem apenas 600 Mb de RAM neste momento, e suporta tudo isto. Grails Brasil tem algo em torno de 2000 a 3000 acessos/dia. Em dias de pico, já vi chegar a muito mais.

E dizem que Grails é pesado :D


0
Peeeerrrrrrfeito cara... Excelente abordageme agora dá pra entender o porque de tão pouca memória consumida.

Uma coisa que me chamou a atenção foi o Item 2. Talvez me enrolei na nomenclatura que você usou, mas não entendi bem a abordagem do pai inconsequente...

Você fala em mapear os domínios sem usar o belongsTo ???

Pow, e se possível, compartilha pra nós o caminho das pedras do MATA-BOTs... Credio que será útil pra todos... rsrrsrs :D

Abs[]
05/03/2012 19:16


0
Oi Adriano,

é um assunto que sou louco para escrever a respeito no meu blog (pretendo fazer isto em breve). A questão é a seguinte: conforme o tempo foi passando, percebi que os livros sobre Grails nos ensinam o GORM errado. Yeap, sei que soa estranho, mas é verdade.

Todo exemplo de relacionamento, vemos algo no seguinte estilo:


class Filho {
static belongsTo = [pai:Pai]
}
...
class Pai {
static hasMany = [filhos:Filho]
}


Não precisa ser bi-direcional o relacionamento. Sim: o filho tem de saber quem é seu pai, mas o contrário não é verdade.

Basicamente é isto.


0
Sim: o filho tem de saber quem é seu pai, mas o contrário não é verdade.


Já havia pensado sobre isso, só não havia parado pra pensar nas complicações (se é que haveriam).

Realmente a nível de BD ainda teremos o relacionamento, mas a nível de Objetos o hasMany não nos ajuda com a lista ???

Ou você prefere ter o controle da consulta dos filhos com base na chave do Pai ??? É mais rápido ??

Porém acho menos produtivo.

Abs []
05/03/2012 22:29


1
Oi Adriano,

é o preço que se paga por esta estratégia: sim, você perde a funcionalidade de poder buscar os filhos diretamente pelo pai, mas pensando um pouco, escrever uma consulta como


def filhos = Filho.findAllByPai(pai)


não é tãããão trabalhoso assim. Outra vantagem arquitetural que eu tenho é a seguinte: meu código por não possuir dependências cíclicas (pai dependendo de filho e vice-versa), me possibilita modularizações no futuro que podem ser interessantes.

Por exemplo: vamos supor que meu sistema cresça pra kcte, e que chegue num ponto em que eu encontre componentes dentro destes que precisam ser reaproveitados. Com a estratégia do pai inconsequente, na prática eu tenho uma árvore de dependências, e não ciclos.

Se é uma árvore, eu posso "podar" os ramos que me interessam, transformando-os em novos módulos/plugins conforme necessário.

Outro ponto: como são menos dependências no proxy a ser criado pelo Hibernate, com certeza é menos memória gasta e menos processamento. Então, no final, o preço que se paga é uma "pixinxa" :)


0
Cara, valew mesmo pela discussão de alto nível proporcionada.

Lembro-me de um tempo atrás ter pensado justamente sobre isso, sobre usar um recurso só porque está lá e facilita e não verificar se ele se torna realmente necessário.

Realmente se torna cada vez mais importante (na verdade sempre foi) nos desapegarmos de tecnologias e pensarmos em soluções, tendo em vista que no final das contas faz toda a diferença.

Lí um pouco sobre o Proxy criado pelo Hibernate no artigo do Gotcha que vc indicou no outro Post, mas confesso que não entendi muito bem o que ocorre.

É isso aí, como pergunta final: você conseguiu pensar em tudo isso logo de cara, ou foi da forma que eu imagino, foi adequando conforme a necessidade ???

Abs []
06/03/2012 13:50


0
Oi Adriano, que bom que te ajudou. Depois divulgue esta discussão porque foi uma das mais bacanas do Grails Brasil até agora.

No caso do Grails Brasil, todos estes princípios foram aplicados de cara por uma razão muito simples: ou eu baixava o custo do Grails Brasil ou matava o site. Então as minhas restrições não permitiam que eu fosse adaptando o projeto de acordo com o desenvolvimento, entende?

Pode-se dizer que foram os requisitos não funcionais do projeto.


0
Perfeito Kico.

Acho que a preocupação é bem válida mesmo quando temos uma excelente infraestrutura a disposição.

Claro, nem sempre é requisito obrigatório e como disse anteriormente, sentar com calma e validar a necessidade é algo que se torna primordial acima de tudo.

Não podemos pensar que só porque agora temos uma excelente infra a nossa disposição, que devemos sair usando a torto e a direita.

Foi o caso de um problema que tivemos no trampo de um servidor que estava com uma App Java Web que caia umas 2 ou 3 vezes por semana por falta de memória...

Achei incrível a resposta do pessoal da empresa dizendo que a solução para o problema, era o cliente disponibilizar um novo servidor com mais memória, pois essa estava insuficiente para a carga de acessos.

Não precisa ser muito chato pra saber que uma queda de 2 - 3 vezes por semana pode ser resolvida com algumas mudanças de cultura de Desenvolvimento. Enfim, hoje em dia pensam de verdade que só porque temos infra a disposição, que temos que sair usando de qualquer jeito.

Minha preocupação é que quero colocar minha App em um Server Cloud... pelo que entendi o mesmo funciona de forma elástica e por demanda... logo, diminuir o consumo do mesmo, creio que me dará uma economia... Isso será bom pra mim e nesse momento quase PRIMORDIAL...

Abs []
06/03/2012 15:46


0
Olá a todos.

Realmente este tópico ficou muito bom, principalmente pela contribuição do Kico sobre as iniciativas utilizadas no Grails Brasil. E pode render muito mais, pois será uma fonte para criar aplicações otimizadas em Grails.

Tenho algumas dúvidas (para o Kico ou para outros usuários que fazem uso das mesmas funcionalidades). A primeira é sobre o uso do Lucene:
O Grails possui o plugin Searchable (http://www.grails.org/plugin/searchable) e você informou que não utilizou outros plugins, além do JQuery no Grails. Dúvidas:
a) Por que optou pelo uso direto do Lucene e não do plugin Searchable?
b) Em uma aplicação que já existe em Grails posso migrá-la posteriormente para utilizar o Lucene? Alguma dica?

Obrigado.
08/03/2012 13:36


0
Para quem se interessou pelo Lucene, tem um link legal:

Grails Lucene

13/03/2012 16:35



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto