Ajuste de desempenho do Rails para produção?

Requests per second:    132.11 [#/sec] (mean)
Time per request:       567.707 [ms] (mean)
Time per request:       7.569 [ms] (mean, across all concurrent requests)

1. 
   Meça o tempo de carregamento do navegador/página primeiro (o navegador faz muitas solicitações, ab está apenas informando sobre uma delas e, geralmente, sua solicitação de página principal não é o problema), obtenha números de linha de base de carregamento de página de ferramentas como www.webpagetest.org ou www.gtmetrix.com para as páginas públicas ou ferramentas do navegador Yslow, google page speed ou dynatrace para as páginas privadas. Se você observar o diagrama de cascata de carregamento da página (o painel 'Net' no chrome/firefox), geralmente mostra que seu html é carregado rapidamente (menos de um segundo), mas todo o resto leva de 1 a 3 segundos para carregar. Siga as recomendações do Yslow/velocidade da página sobre como melhorar (certifique-se de estar usando o pipeline de ativos do Rails 3.1 em toda a sua extensão)
   
2. 
   Leia seus arquivos de log/nova relíquia para encontrar o ponto ideal da solicitação 'mais lenta/mais frequentemente atingida' e faça um perfil do que acontece para essa solicitação (é um ruby ​​lento/muito uso de mem ou muitas consultas?) Você precisa ter uma maneira confiável de detectar e monitorar problemas de desempenho, e não apenas mudar as coisas aleatoriamente. Depois de identificar algumas áreas de destino, crie scripts de teste para ajudar no teste antes/depois e prove que sua alteração ajuda e detecte se uma regressão se aproxima.
   
3. 
   A falta de índices nas colunas db é um dos problemas mais comuns e mais fáceis de resolver. Execute explicação nas consultas de destino ou examine seu log de consultas lentas para ver o que o planejador de consultas está fazendo. Adicione índices para chaves estrangeiras, colunas de pesquisa ou dados primários (índice de cobertura) conforme apropriado. Teste novamente com dados de produção reais para provar que isso faz a diferença. (você pode executar a explicação no heroku, bem como executar consultas para índices ausentes ou não utilizados)
   
4. 
   A maioria dos aplicativos Rails de baixo desempenho sofrem de consultas N+1 porque é muito fácil escrever order.owner.address.city e não pensar no que acontece quando isso está em um loop. Consultas N+1 não são necessariamente consultas lentas, então elas não aparecem no log de consultas lentas, é apenas que existem muitas delas, e é mais eficiente fazer tudo de uma vez. Use :include ou .includes() para carregamento antecipado desses dados, ou veja como fazer sua consulta de outra maneira.
   
5. 
   Analise o fluxo do seu aplicativo e procure oportunidades de armazenamento em cache. Se o usuário alternar entre a página de índice e uma página de detalhes e vice-versa, talvez uma visualização ajax dos detalhes, sem sair da página de índice, forneça os dados necessários de maneira mais rápida. Escrevi algumas mais pensamentos sobre isso no meu blog