Como é a experiência de escalabilidade do Ruby on Rails?

[kicolobo]

Ruby on Rails tá sendo um aprendizado bem interessante pra mim: to aprendendo HORRORES com ele, mas vez por outra topo por aí com questionamentos a respeito da escalabilidade do Ruby on Rails.

Muitas pessoas apontam para o fato do Twitter ter saído do framework por questões de performance, mas neste caso era mais uma questão arquitetural do que por conta do framework em si.

Na outra ponta, tenho diversos desenvolvedores Rails dizendo que escala sim: e com certeza deve escalar, basta ver alguns casos de sucesso como o Gitlab ou o Discourse (que mantém este fórum) por exemplo.

Então gostaria de levantar esta discussão aqui com vocês que já trabalharam com o framework: como é a experiência de escalabilidade do framework? Já tiveram problemas? Qual a experiência hoje?

Comparado ao Java no que diz respeito a consumo de memória (pergunta altamente complicada dada a variação nos frameworks: Micronaut por exemplo): como fica? Consome menos memória ou mais na prática? Os servidores precisam ser maiores?

PS: voltei de férias e to cheio de discussões pra tratarmos aqui. Aguardem!

[joao]

Eu usei o Rails 3 e peguei o começo da migração para o 4. Então, só posso falar dessa época dele e um pouco mais da metade desse tempo use JRuby ao invés de do Ruby MRI o que faz toda a diferença.

No Rails com o MRI só tive experiência de rodar o ambiente de produção com tudo em uma máquina só por questões de curso e cloud na época não ser tão forte que nem é hoje. Usava Linode na época e a máquina era razoável, 1 vCPU, 4 GB de RAM para rodar NGINX, Rails, Memcache e MySQL e atendia bem os clientes, o maior problema nossa era um cliente que fazia parte do programa de pontos da Ipiranga que quando rolava email marketing sem avisar explodia o servidor.

Na experiência com JRuby foi mais interessante, usavamos o Tomcat no Rails para fazer deploy, o carregamento inicial da aplicação era bem lento mas depois que estava de pé era bem resiliente, nesse caso já tinhamos o ambiente melhor feito com o MySQL configurado em outra instância e conseguiamos escalar tanto na horizonta e vertical a aplicação que funcionava, sem contar que podiamos usar Threads por conta do suporte da JVM. Na época, nosso sistema era o coração do SAC de um grande ecommerce brasileiro e atendia bem.

Nas duas experiências o que mais senti era que se você usar com o carinho o ActiveRecord vc consegue entregar bons resultados. As vezes, ele faz consultas muito complexas para coisas simples. Nesses casos, usamos o Arel para escrever código que gerariam consultas SQL melhores mas nunca usar SQL direto.

Abuse de caching, utilizavamos bastante o fragment caching, não sei se ainda tem já que SPA dominou, na época era quase tudo server rendering e ajudava bastante.

Se lembar de mais algo comento depois, por hora é isso que lembro.

[kicolobo]

Interessantíssimo você mencionar o JRuby: como era a compatibilidade com o Ruby on Rails nesta época? Conseguiam usar todas as GEMs?

[joao]

quase tudo funcionava a msm gem p/ ambos, só alguns casos que mudavam quando tinha q usar FFI como por exemplo o Nokogiri para tratar imagens. Nesses casos era só colocar uma condicional no Gemfile para lidar com isso e era tranquilo. =)

[lucasarruda]

Ruby está cada vez mais rápido e otimizado e a promessa é um Ruby 3 x 3 (3 vezes mais rápido que o 2).

De toda maneira, vejo a questão de memória mais ou menos como o Java. Talvez Java gaste tipo o dobro. Mas Java obviamente por ser compilado em bytecode será mais rápido.

O ruby acabou de adicionar um JIT o que também trará benefícios futuros, mais ainda não tem toda aquela otimização do Java, é claro.

De um modo geral podemos dizer que Ruby e Rails escalam muito bem. Na verdade depende muito mais de como sua aplicação é construída, se as queries estão otimizadas, se usa cache, etc etc. Esse fórum por exemplo é todo em Ember com Rails e escala muito bem e é bem rápido. Shopify por exemplo é um dos maiores produtos em rails é escalou muito bem.

O caso do twitter é mais emblemático por 2 motivos: pegou rails e ruby antigos e ainda pouco otimizados. É um aplicação que, como bolsa, tem que chegar o mais perto possível de real-time, assíncrona e veloz. Isso aí só com JVM, C, Go, Rust e Elixir/Erlang. Não tem como você ter uma aplicação assim em 100% Rails ou Ruby. Simplesmente não foram feitos para isso. Embora o twitter ainda aparentemente use um pouco, moveram essa parte toda para Scala.