Abbiamo appena rilasciato una nuova immagine container che verrà utilizzata al prossimo ./launcher rebuild app. Come sempre, non è necessario modificare alcuna configurazione, a patto che abbiate seguito la nostra Installazione Standard Ufficiale di Discourse. Detto questo, sono state introdotte nuove funzionalità che aiuteranno alcune installazioni.
Redis 6
Facciamo un uso massiccio di Redis in molte parti di Discourse, sia per la cache, Sidekiq, MessageBus, che per i Distributed Locks e i Rate Limits. Nel complesso, è stato una scelta estremamente solida per noi.
Tuttavia, in alcuni carichi di lavoro molto specifici, Redis potrebbe diventare un collo di bottiglia. E a causa della natura single-thread di Redis, unita alla nostra incapacità di utilizzare più istanze a causa degli script LUA, questo rappresentava un collo di bottiglia difficile da aggirare.
Fortunatamente, Redis 6 introduce il supporto per l’uso di un thread pool per le operazioni di I/O e, durante i nostri test, ha funzionato molto bene con i cluster Discourse limitati da Redis.
Quindi, se state eseguendo su una macchina con molti core CPU e le metriche mostrano che Redis fatica a gestire il carico, ora potete attivare l’uso dei thread per le operazioni di scrittura tramite la sezione params di app.yml:
params:
redis_io_threads: "4" # 1 disabilita la funzionalità, n>1 utilizza n-1 thread aggiuntivi per le scritture I/O
Immagine più piccola
Abbiamo scelto di distribuire un’immagine container di grandi dimensioni nelle prime fasi del progetto, per rendere più semplice a chi non è tecnico l’esecuzione di Discourse e per gestire tutte le dipendenze necessarie, il versionamento, gli aggiornamenti, ecc.
Detto questo, di recente l’immagine compressa ha superato 1 GB, e questo era un po’ eccessivo.
Quindi, per mitigare l’aumento costante delle dimensioni dell’immagine, abbiamo spostato il codice sorgente di Discourse all’interno dell’immagine: da una copia completa del codice sorgente a un “clone superficiale” (shallow clone) contenente solo la versione più recente del codice.
Questa modifica riduce le dimensioni dell’immagine compressa del 25%, il che si traduce in meno spazio server necessario e rebuild più rapidi quando viene rilasciata una nuova immagine. Dovrebbe anche controllare la crescita dell’immagine nel tempo.
L’abbiamo testato su tests-passed/beta/stable, sia con rebuild che con aggiornamenti web, e non rompe alcun percorso standard. Tuttavia, gli utenti che eseguono operazioni git più esotiche negli hook di app.yml potrebbero dover adattare le loro personalizzazioni.
And there is a way to set the DB. .