Joomla 5 Joomla 6 articoli
-
@ElenaEffe ha detto in Joomla 5 Joomla 6 articoli:
@luX0r75 Grazie della risposta. Anch'io credo che avendo un pelino più di risorse (VPS di media natura) la situazione cambierebbe.
Ho fatto innalzare il PHP memory_limit a 768 ed ha risorse dedicate 4 CPU Cores 5GB Memory essendo un semidedicato. Tuttavia noto due cose. Un altro sito che ho che ha 700 articoli e non 60.000 come quello in oggetto (e stessa versione di Joomla! 5.4) in backend è reattivo come il frontend.
Se così fosse credo sarebbe sproporzionato avere 200 metri quadri ed utilizzare solo camera bagno e cucina... solo per il backend.
Per quanto riguarda il DB forse dovrei pensare ad un cronjob che ottimizza le tabelle ogni 12 ore. Tuttavia il problema, cronometro alla mano, rimane anche con una ottimizzazione. Salvare un articolo di media entità o solo chiuderlo senza aver fatto modifiche mi chiede tra i 5 e gli 8 sec. Idem spostarmi tra le varie aree.
Se individuo il problema sarà mia cura renderlo noto.
Ringrazio dell'attenzione.Lo fa solo con "Salva" o anche con "Salva e chiudi"?
Perché potrebbe essere un problema di caricamento dati dopo il salvataggio.
In quel caso potresti abilitare il debug di Joomla e vedere quale query impiega più tempo per essere eseguita.
Da lì poi è semplice risalire alle tabelle implicate e verificare che non siano piene di robaccia. -
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.
