Esecuzione di YJIT di Ruby 3.2 in produzione su Discourse

No Discourse, temos estado ansiosos para adotar o YJIT desde que a equipe de Infraestrutura do Ruby on Rails da Shopify o declarou pronto para produção. Após testemunhar benchmarks locais promissores, começamos a executar nossas aplicações Rails de produção com o YJIT do Ruby 3.2 habilitado em clusters selecionados no início de maio de 2023. Em seguida, passamos algum tempo medindo seu desempenho no mundo real. Estamos entusiasmados em compartilhar os resultados positivos que observamos. Com base nessas descobertas, agora habilitamos o YJIT em toda a nossa hospedagem, e os auto-hospedeiros podem optar por fazer o mesmo.


Este é um tópico de discussão complementar para a entrada original em https://blog.discourse.org/2023/05/running-ruby-3-2s-yjit-in-production-at-discourse/
21 Mi Piace

Abbiamo iniziato il benchmarking di Discourse+YJIT da novembre '22 e abbiamo iniziato a eseguire Meta con YJIT in modo intermittente da gennaio di quest’anno. YJIT è uno dei motivi per cui abbiamo accelerato l’aggiornamento da Ruby 2.7 a Ruby 3.2 in pochi mesi e sono entusiasta che sia finalmente arrivato. E ancora di più perché i miglioramenti che arriveranno per Ruby 3.3 sembrano ancora migliori!

14 Mi Piace

Lo sviluppo che Ruby sta ricevendo è piuttosto impressionante… Pensavo che tutti i ragazzi fighi fossero su Python in questi giorni?! :sweat_smile:

Ben fatto Team per aver mantenuto il passo con la roadmap di Ruby.

12 Mi Piace

Probabilmente una domanda stupida, ma il “file di definizione del container” è il file app.yml? Non l’ho mai sentito chiamare così prima. Grazie!

3 Mi Piace

Sì, è così. Abbiamo usato il nome lungo poiché alcune persone potrebbero rinominare o avere più file “app.yml”.

5 Mi Piace

Sarebbe molto interessante un confronto tra Ruby 2.7 e 3.2 con JIT!

2 Mi Piace

Dalle mie note del 4 gennaio:

Riprovato ora

Ruby Server p categories home topic categories user home user topic user categories admin home admin topic admin
2.7.5 Unicorn 50 34 59 36 82 112 93 67 94 72
3.1.2 Unicorn 50 34 61 36 82 112 91 67 94 70
3.2.0 Unicorn 50 33 59 36 82 111 90 68 92 72
3.2.0 +YJIT Unicorn 50 25 42 29 67 89 77 58 76 56

2.7 a 3.2 + YJIT Speedup

Speedup categories home topic categories user home user topic user categories admin home admin topic admin
1.36 1.40 1.24 1.22 1.25 1.20 1.15 1.23 1.28

7 Mi Piace

E senza dati misurati e basato su ciò che un singolo o pochi utenti sentono e vedono.

Per me questo forum è più lento da un po’. Vedo un cerchio che gira per un breve momento quasi ogni volta che apro un argomento. Certo, può e quasi sicuramente proviene dai server e dalle distanze tra USA ed Europa. Ma Meta è più lenta di prima.

Ho iniziato a usare YJIT sul mio forum e quando il server è in Germania e gli utenti sono finlandesi, tutti dicono che tutti gli argomenti si aprono più velocemente. Questo è in realtà abbastanza divertente perché non possiamo vedere cambiamenti nei tempi di caricamento puri inferiori a 200 ms.

1 Mi Piace

Sto pensando da tempo a un tempo di caricamento della pagina fisso (o coerente). Dove i tempi di caricamento per ogni pagina e ogni utente siano il più coerenti possibile.

Le informazioni sugli utenti finlandesi sono interessanti, questo mi ha fatto chiedere se potremmo instradare gli utenti in base al GEO IP o alla latenza verso server diversi con carichi diversi solo per risparmiare loro tempo di risposta.

1 Mi Piace

Questi risultati non tengono conto anche dell’accesso al database?

Ho abilitato questo su exiges.com.

Devo ammettere di non aver eseguito benchmark, ma posso notare una differenza nel modo in cui argomenti e thread si aprono.

Deve essere un passo positivo poiché gli utenti non mi hanno informato diversamente :slight_smile:

1 Mi Piace

Sì, stiamo misurando solo il tempo impiegato nell’esecuzione del codice Ruby, escludendo le query al database e i comandi Redis nei tempi.

1 Mi Piace