Moodle SCORM con utenti contemporanei: cosa si rompe quando tutti aprono, navigano e fanno commit insieme.
Misuriamo picchi di launch e commit, saturazione PHP/DB e comportamento del player quando l’aula digitale e piena.
A inizio webinar o fine modulo: player lenti, commit falliti, timeout proprio quando tutti sono dentro.
A riposo il corso e ok. Sotto concorrenza emergono pool PHP esausti, lock DB e storage lento sui package.
Checklist di osservazione del picco.
Finestra temporale
Orario esatto del degrado e numero sessioni SCORM attive.
Metriche runtime
php-fpm active, DB CPU/locks, latenza disco moodledata.
Sintomo utente
Lento al launch, al commit periodico, o solo a fine corso?
Dove guardare: richieste player e commit lente.
URL scorm correlate a p95 alto nell’orario critico.


Dove guardare: listen queue e max children.
502/timeout quando la coda PHP esplode.
Dove guardare: lock su tabelle tracking.
Update concorrenti su scorm scoes_track.


Possibile causa: auto-commit troppo frequente.
Ogni slide x N utenti = tempesta write.
Possibile causa: asset pesanti da NFS lento.
Launch lento per tutti i nuovi ingressi.


Possibile causa: session handler inadatto al picco.
File session su disco saturo.
Possibile causa: cache/session senza Redis.
CPU e I/O crescono linearmente col traffico.


Possibile causa: job pesanti durante l’aula.
Cron e SCORM si contendono DB.
Possibile causa: polling JS aggressivo.
Beacon continui anche a corso fermo.


Correzione: pool PHP e DB calibrati al picco SCORM.
Non alla media giornaliera.
Correzione: ridurre frequenza write inutili.
Authoring + setting player coerenti.


Correzione: CDN/cache per statici del pacchetto.
Launch meno dipendente dallo storage LMS.
Verifica: load test sul percorso reale.
Launch, navigazione, commit, chiusura sincronizzati.


Procedura per giorni di picco.
Monitor, soglie, chi scala cosa.
Misuriamo prima di comprare server.
Atlas Learning lega sintomo SCORM a bottleneck infrastrutturale.


Sotto carico non chiedo quanti utenti avete iscritti: chiedo quanti commit al minuto.
Da li nasce un piano su PHP, DB, storage e design del pacchetto.
Atlas Learning opera come partner tecnico: leggiamo log, riproduciamo il caso e interveniamo sul livello responsabile, senza sostituirci alla vostra governance di piattaforma.
Cosa dicono i clienti che lavorano con Atlas Learning.
Le recensioni vengono mostrate dinamicamente tramite Trustindex.
Domande frequenti su SCORM e utenti contemporanei.
Basta alzare la RAM?
Raramente da sola: spesso pool, DB locks o I/O.
Il pacchetto puo essere colpevole?
Si: polling e commit eccessivi amplificano il picco.
Serve Redis?
Spesso aiuta session/cache sotto picco; si valuta sui numeri.
Fate load test?
Si, su scenari d’aula realistici come partner tecnico.
Il SCORM regge in laboratorio ma non in aula piena?
Condividi orari di picco, metriche php/DB se disponibili e tipo di pacchetto.