Joomla 5 Joomla 6 articoli
-
Buongiorno.
Posto qui per evitare di disturbare fuori categoria.
Devo migrare gli articoli da Joomla! 5 ad una nuova versione di Joomla! 6.
Prima di illustrare cosa ho fatto ed eventuali difficoltà chiedo venia ed aiuto per comprendere in quale categoria del forum devo postare.
Ringrazio per l'attenzione -
tranquillo, posta pure il tuo problema.
-
M mangi-1 ha spostato questa discussione da Off Topic
-
Grazie della risposta.
Tutto nasce dall'esigenza di fare un test di velocità nel backend, nella speranza che il 6.1 fosse più reattivo.
Avevo problemi nel fare un upgrade da Joomla! 5.4 a Joomla! 6.1 per via di alcuni non ben chiariti conflitti con un componente (poi risolti). Pertanto ho fatto prima una installazione nuova della versione 6.1 e poi tramite PHPMyAdmin, con le dovuta accortezze sulle tabelle ho uploadato via Terminal i contenuti però mi dava su articles
"No Matching Results". Evidentemente il workflow andava sistemato su questo DB con le migliaia di contenuti.
Lavorando su PHPMyAdmin in SQL, con opportune istruzioni, ho risolto.
Fatto il test, anche cambiando il PHP 8.4 la velocità è pressoché identica.
Ho comunque poi fatto un upgrade diretto da 5.4 a 6.1 risolvendo i conflitti. Il test mi fornisce una velocità identica nel salvataggio o chiusura degli articoli.
Quindi due installazioni a Joomla 6.1 mi hanno fornito lo stesso risultato in backend e, purtroppo per me, lo stesso tempo in secondi della 5.4.
A questo punto, non vorrei essere approssimativa o di affermare una ovvietà, ma temo che avere decine di migliaia di articoli su Joomla!, senza risorse dedicate di un certo tipo, probabilmente non risolve la performance e la reattività del sito.PS in frontend il sito è una scheggia.
-
Ciao Elena.
È capitato anche a me un paio di volte su siti di clienti che avevano decine di migliaia di articoli.Uno dei due era stato creato decine di anni fa su Joomla 1.5 e aggiornato fino alla versione 4.
Io mi sono occupato dell'aggiornamento alla versione 5, quindi non so se negli update precedenti avessero fatto casini. Abbiamo risolto (leggi migliorato la velocità) mettendo tutto su un server VPS.L'altro caso: un sito web in Wordpress su cui è stato fatto il porting su Joomla.
Non ti dico cosa ho trovato sul DB.Solo per dirti che non escluderei che vada in affanno con decine di migliaia di articoli.
Come non escluderei che tutto possa dipendere da aggiornamenti che non hanno filato come dovrebbero.Da sviluppatore: la velocità di PHP migliora di versione in versione. Il collo di bottiglia è altro.
Se dovessi scommettere, propenderei per il DB. -
@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. -
Dipende molto anche dal tipo di CPU che monta il server. In giro si trova spesso — passatemi il termine — "robaccia" da 2.2-2.8 GHz, CPU datate o pensate per il risparmio energetico più che per le performance.
I nostri Cloud Hosting (VPS dedicati managed) montano tutti CPU a 5 GHz. Cosa significa nella pratica? Che, a parità di tutto il resto, PHP gira fino al 127% più veloce rispetto a una CPU da 2.2 GHz (+79% rispetto a una da 2.8 GHz): tempi di risposta più bassi, pagine che si caricano prima, backend amministrativi più reattivi.
Sulla frequenza di clock incidono direttamente le operazioni single-thread come l'esecuzione di codice PHP, le query non parallelizzabili e il rendering lato server — esattamente i colli di bottiglia tipici di WordPress, Magento, PrestaShop e dei CMS in generale.Se vuoi info scrivi direttamente a info@host.it
-
@mangi-1 Non fa una piega. Indagherò.
-
@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.
-
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!
