Joomla 5 Joomla 6 articoli
-
Io ho trovato molto buoni i servizi offerti da Keliweb e Ergonet.
-
Sui providers, grazie... se ne può parlare? Ho evitato, perché pensavo fosse vietato.
Grazie dei suggerimenti tecnici.
Empiricamente questi i tempi.
Solo entrata in backend dopo le credenziali 8/9 sec.
Apertura articolo nuovo o già editato immediata o al massimo 1 sec.
Solo "Salva" anche qui quasi immediato con piccola variazione.
"Salva e chiudi" 8/9 sec.
Solo "Chiudi" senza variazione di testo 7 sec.
Da "System" ad "Articles" 8/9 sec.
Abilito il debug e verifico. Grazie. -
Il problema è il caricamento delle liste, ci sono varie issues su github ancora aperte (tipo https://github.com/joomla/joomla-cms/issues/42313 ). Purtroppo è un problema noto, so che ci sono un po' di PR a riguardo (tipo questa https://issues.joomla.org/tracker/joomla-cms/45542 ) ma non so se e quanto qualcuno le stia seguendo. Purtroppo è un problema strutturale di joomla di come gestisce i numeri grandissimi.
-
@jabba Ah, nella mia poca conoscenza immaginavo. Comunque farò un debug e vedo se esce fuori qualcosa.
Grazie dei preziosi contributi di ciascuno. -
Questa PR sembra promettente, ma mancano dei tester, se vuoi provare in un sito di test: https://github.com/joomla/joomla-cms/pull/45660
-
Buonasera a ciascuno. Provo a spiegare come è stato risolto il problema. Anzitutto la diagnosi. Come mai il sito in frontend è molto reattivo e veloce ma non lo è in backend con il sito di 60.000 e passa articoli? Questo perché dal salvataggio di un solo articolo il sistema rilascia l'articolo dopo aver concluso tutto (Releasing edit ID). Pertanto in "/administrator/logs/" ho letto cosa mi comunicava l'ultimo articolo salvato. Non bastava la deframmentazione del DB ma il collo di bottiglia era proprio la RAM dell'hosting. Scrivere e aggiornare indici su 60.000 articoli richiede che il parametro innodb_buffer_pool_size di MySQL sia impostato su un valore consistente. Se sei su un hosting condiviso, il server limita la velocità di scrittura per non sovraccaricarsi. Poiché la sola tabella jos_content mi pesa oltre 650 MB, non entrava fisicamente nella memoria RAM veloce del server. Di conseguenza, a ogni salvataggio il server era costretto a scrivere i dati direttamente sul disco fisso (I/O rigido) invece che nella memoria volatile, rallentando il processo. Una pesante query di lettura (SELECT) che si attiva durante il salvataggio. Non parliamo di RAM totali (che qui sono 5 gb nel semidedicato che uso) ma il parametro innodb_buffer_pool_size della configurazione del DB (my.cnf), vanificando l'intervento del pur performante Processore. Pertanto ho chiesto a quanto era impostato questo parametro. Dapprima si sono un po' irrigiditi poi da soli sono giunti alla conclusione, query alla mano, che dovevano innalzare innodb_buffer_pool_size ad un minimo di un 1 GB per facilitare non solo me ma anche tutti gli utenti che hanno molti articoli nei loro CMS. Ed ora anche il backend è estremamente performante. Risolvendo questo problema ho poi fatto l'upgrade a 6.1 e tutto è reattivo. Spero possa essere utile. Auguro buona serata.
-
Molto interessante, grazie per il feedback!
-
@ElenaEffe Ciao Elena.
Feedback molto dettagliato. Tornerà senz'altro utile.Grazie e buon lavoro!
-
Grazie a Voi per gli spunti e l'aiuto. Condividere mi sembrava il minimo.
-
Buonasera!
Grazie mille per aver condiviso questa diagnosi così dettagliata — è esattamente il tipo di contributo che rende questa community preziosa.
Hai centrato un problema che in molti danno per scontato o attribuiscono a Joomla stesso, quando invece la radice è tutta nell'infrastruttura server. Riepilogo per chi legge e vuole capire al volo:
Il problema: backend lentissimo al salvataggio degli articoli su un'installazione Joomla con oltre 60.000 contenuti.
La causa reale: il parametro
innodb_buffer_pool_sizedi MySQL era troppo basso. Con una tabellajos_contentche supera i 650 MB, il server non riusciva a gestire tutto in RAM e scaricava le operazioni di scrittura direttamente su disco — I/O fisico, lentissimo per definizione.La soluzione: portare
innodb_buffer_pool_sizead almeno 1 GB, in modo che MySQL possa lavorare davvero in memoria volatile.Una cosa su cui vale la pena soffermarsi: hai fatto bene a leggere i log in
/administrator/logs/— sono spesso il punto di partenza ignorato da chi cerca di risolvere tutto "a sensazione".Sul discorso hosting: su un piano condiviso questo tipo di intervento è quasi impossibile da ottenere, perché la configurazione di MySQL è condivisa tra decine o centinaia di utenti. Su un semidedicato o VMS hai già più leva, ma serve comunque un provider disposto ad ascoltarti — e non sempre è scontato. Chi è su Host.it con un piano semidedicato o superiore può fare richiesta direttamente ai tecnici, che hanno visibilità sulla configurazione del server e possono intervenire su parametri come questo senza lasciare l'utente solo davanti a un ticket generico.
Ottima anche la scelta di aspettare la risoluzione prima di fare l'upgrade a Joomla 6.1 — procedura corretta, così non si rischia di confondere i problemi.
Buona serata anche a te, e grazie ancora per la condivisione!
