Sobre escabilidade, onde o mesmo faz uma comparação à arquitetura Java.
Não concordo e pretendo responder ao autor em seu Blog, entretanto como temos ao menos alguns especialistas no assunto como o Louds, gostaria de debater a questão antes.
Até onde eu sei o RubyOnRails é baseado em processamento CGI. Mesmo sendo FastCGI, você tem um processo à cada requisição.
Servlets possuem a implementação Multithread, tendo seu “peso” de construção atenuado.
Fora que a máquina virtual java é m,uito superior ao interpretador Ruby.
Queria saber sobre tal comparativo. Agora esse esquema separado de LoadBalance, parece ser bem bacana
Kenobi, se isso puder te ajudar o RubyonBr publicou a analise deles com o antiga configuracão que eles tinham. Segundo os admins do site, dentro em breve publicarão a analise com a configuracao atual =)
[quote=Proteu Alcebidiano]Kenobi, se isso puder te ajudar o RubyonBr publicou a analise deles com o antiga configuracão que eles tinham. Segundo os admins do site, dentro em breve publicarão a analise com a configuracao atual =)
Proteu, eu já tinha visto essa matéria, até vi a palestra do Ronei no seminário sobre performance e bati um papo, fiz algumas indagações sobre tal …
O ponto seria o paradigma de processamento por request x multithread e seu peso.
Na matéria acima, o Fábio Akita comparou com Java e achei a comparação muito séria. Até postei em seu flog, pois acredito que qualquer comparação precisa ter o mínimo de métrica.
[quote=cv]Se vc ta na duvida entre escolher Java ou Rails pro proximo projeto, certeza que performance vai ser tanto problema assim?
Rails (e apps LAMP em geral) sao normalmente escaladas na horizontal, e ai o problema eh literalmente jogar mais hardware no treco.
Nao eh melhor se concentrar em fazer uma aplicacao que atraia essa carga toda, pra comeco de conversa? ;)[/quote]
Concordo plenamente. Num dos meus últimos projetos o cliente tinha temor de adotar Java justamente por esta razão e usamos este argumento (deixe os usuários aparecerem primeiro). Posso garantir que até hoje estão bastante satisfeitos, mesmo depois do sistema ter que ser trocado de servidor porque o número de acessos estava muito grande. Problema de escalabilidade resolvido sem estresse
CV tocou no ponto chave da coisa: quem segue a filosofia do ruby valoriza mais a hora de trabalho de quem está pensando / aplicando a solução do que o hardware que será utilizado. O modo de balancear carga em aplicações rails nos leva em colocar mais hardware mesmo.
Mas como toda filosofia, adota quem achar adequado para seu uso
Bom, ressaltando mais uma vez precisa sim de metrica, mas observando e cruzando alguns criterios. Testar com o mesmo hardware, dependendo da aplicação seria inapropriado.
Acho válido pensar no seguinte: colocar as aplicações para funcionar com desempenho o mais proximo possivel (incluindo hardware para equiparar a coisa) e ver o quanto se gastou com hardware e o quanto se ganhou de tempo / custo de desenvolvimento entre as duas aplicações que estiverem sendo comparadas. Acho que é um critério razoável pra qualquer comparação quando temos um ganho de tempo x hardware.
[quote=cv]Se vc ta na duvida entre escolher Java ou Rails pro proximo projeto, certeza que performance vai ser tanto problema assim?
Rails (e apps LAMP em geral) sao normalmente escaladas na horizontal, e ai o problema eh literalmente jogar mais hardware no treco.
Nao eh melhor se concentrar em fazer uma aplicacao que atraia essa carga toda, pra comeco de conversa? ;)[/quote]
Concordo com esse ponto de vista… Será que uma aplicação Java é tão performática como uma aplicação PHP ou Ruby para um único usuário? Será que todo esse overhead compensa?
Até onde sei isso não é um “feature” do rubyonrails mas sim do servidor web/container ruby web que você irá escolher para rodar sua aplicação. O mongrel pro exemplo é uma thread por request.
