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.