Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Ruby Performance Roundup: Ruby 1.9.1 Performance no Mundo Real, GC vs EventMachine, Ruby Compiler
Postado por Werner Schuster , traduzido por Ricardo Almeida em 21 Mai 2009
Um argumento para usar Ruby 1.9.1 é o aumento significante de performance. Um novo resultado de benchmark vem do mundo real, aplicações existentes e pit 1.8.x, JRuby e 1.9.1 contra cada um dos outros:
Nós portamos Acunote - nosso sistema de gerenciamento de projeto online e o software Scrum, ambos JRuby e Ruby 1.9, e rodamos nossos conjunto de benchmark de performance.
Ruby 1.9.1 e JRuby ambos fornecem melhoras significantes ao 1.8.6, com 1.9.1 na liderança do JRuby, apesar de algumas discussões no comentário sobre maneiras de melhorar a performance do JRuby com alguns flags em linhas de comando.
Melhoras na performance no 1.9.1 não chegam somente de uma VM mais rápida, mas também de algumas novas funcionalidades. Muhammed Ali mostra como escalar uma aplicação web usando Fibers do Ruby 1.9.1. Por outro lado, Muhammed também comentou um questão com vazamento de memória no Object#extend no 1.9.1.
Entretanto, 1.8.6 é ainda a única opção para alguns projetos, devido a algumas bibliotecas perdidas no 1.9.1. Por causa disso, existe muito interesse na correção de alguns estrangulamentos no 1.8.6. Joe Damato foi investigar algumas das questões em seu blog. Por exemplo, ele investigou a história por trás do --enable-pthread e porque desativar essa configuração trás 30% de ganho na performance. Em outro artigo, Joe e Aman Gupta investigaram o problema com o Ruby GC - e veio com um pequeno patch que corrige alguns problemas com o GC e EventMachine:
* Acelera a GC em 2 a 3 vezes por causa da enorme diminuição no tamanho da pilha do frame.
* Corrige um bug aberto na EventMachine onde usa threads com Epoll que causa muita lentidão. A razão é que cada thread vai herdar aproximadamente 800,000 bytes de pilha que é copiado nele e fora toda troca de contexto.
* Isso resulta em um aumento de 500 requests/segundo a 7000 requests/segundo quando usa Sinatra+Thin+Epoll+Threads. Isso é muito mal.
Finalmente, Viktor Hokstad escreveu uma serie em compilando Ruby já a algum tempo. Um artigo recente fala sobre algum desses problemas em fazer Ruby mais rápido e possíveis otimizações.
Nenhum comentário
Acompanhar Discussão Responder