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/
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!
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.
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.