Sto tribolando parecchio con l’installazione di WordPress che gestisce Attivissimo.me: per motivi ignoti e nonostante vari interventi drastici per rimuovere plugin e file ridondanti, purgare cache e ispezionare log, da qualche giorno la pagina della Bacheca dalla quale posso postare un nuovo articolo o editarne uno esistente è diventata lentissima (ci mette vari minuti a caricarsi).
Lo stesso avviene, almeno per me, quando tento di sfogliare Attivissimo.me come lettore. Succede anche a voi?
Sto allestendo un WordPress alternativo in hosting su WordPress.com: lo trovate presso Paoloattivissimo.com. È ancora in bozza, ma i contenuti sono sincronizzati con quelli di Attivissimo.me, a parte i commenti, che per ora non sono disponibili.
Ciao Paolo,
Ti confermo che il sito è molto lento. Mi sono permesso di fare una veloce analisi.
Rete e DNS sono a posto:
gianlu@trm:~/pa$ mtr -4 -rwzc 50 attivissimo.me
Start: 2025-10-07T13:18:49+0200
HOST: trm Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway 0.0% 50 0.8 0.8 0.6 1.1 0.1
2. AS30722 net-2-36-114-1.cust.vodafonedsl.it 0.0% 50 9.6 6.0 4.0 18.4 2.8
3. AS??? ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
4. AS??? ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
5. AS??? 185.210.48.126 0.0% 50 4.2 4.7 3.8 12.1 1.7
6. AS??? 185.210.48.127 0.0% 50 12.7 5.6 4.0 17.9 2.8
7. AS3356 ae1.3122.edge9.frf1.neo.colt.net 4.0% 50 17.6 19.7 17.1 34.5 4.5
8. AS3356 62.67.66.34 0.0% 50 17.5 18.6 17.0 38.1 4.0
9. AS??? ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
10. AS??? ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
11. AS29169 et19.edge-2.bi2.gandi.net 0.0% 50 24.5 24.5 23.9 25.0 0.2
12. AS29169 te0-0-2-0.core2-lux.gandi.net 0.0% 50 24.9 25.0 24.7 25.4 0.2
13. AS29169 et3-43.dcgw-1r.bi2.gandi.net 0.0% 50 24.7 24.7 24.4 25.1 0.2
14. AS29169 gpaas4.dc2.gandi.net 0.0% 50 24.7 24.8 24.5 25.2 0.2
Il problema è lato tuo server, 94 secs di Time to first byte significa che ci mette un sacco a generare la pagina.
Non sono neanche Javascript bloccanti. Ho fatto i test con curl che non renderizza, non esegue javascript e non scarica risorse linkate nell’html:
gianlu@trm:~/pa$ curl -w “@curl-format.txt” -o /dev/null -s https://attivissimo.me
time_namelookup: 0.003760s
time_connect: 0.028904s
time_appconnect: 0.064059s
time_pretransfer: 0.066901s
time_redirect: 0.000000s
time_starttransfer: 94.558800s
———-
time_total: 94.633016s
a 94.55 secs il gateway va in timeout, presumo che davanti ad apache/nginx tu abbia un proxy cache (varnish?) ed un TLS offload davanti a Varnish (hitch/nginx/haproxy). Non ho fatto un service scan sulla 443.
Riprovando dopo la prima curl vedo che ora (13:27 UTC+2 07/10/2025) risponde varnish con un “backend fetch failed” coda piena o hai appena riavviato apache perchè il sito non va 🙂
Gli statici pure non stanno rispondendo /robots.txt va in BFF.
Questo ci suggerisce che il problema sta sulla tua installazione di wordpress/server e le cause possiamo raggrupparle in:
1)Cambiamento al codice PHP (aggiornamenti, plugins etc etc)
2)Database (indici mancanti o da rigenerare/ parametri da modificare perchè i dati sono cresciuti)
3)Infrastruttura. Non so se il server è uno private o shared hosting, se è una VPS o un bare metal dedicato. Può anche essere che un altro cliente che risiede sullo stesso tuo hosting od ha una VPS sullo stesso tuo hypervisor sia la causa se la segmentazione delle risorse non è fatta bene o il provider fa overbooking.
4)Traffico anomalo: scraper/scanner che ti stanno rompendo i maroni.
Non so se hai accesso ssh al server, se si la prima cosa che guarderei è eventuale traffico anomalo, hai varnish ed il compito di analisi è abbastanza facile, ti lascio un paio di comandi utili:
1) Requests per IPs. Questo ti ordina gli ip che fanno più richieste, se noti un IP che fa molte più richieste di altri è un campanello d’allarme per scanner/scraper
varnishtop -c -i reqstart -f
2) Backend Request per URLs. Questo ti mostra le url che vengono girate al backend (quindi non cachate da varnish) Se noti molte richieste ad una url sensibile (wp-login.php, xmlrpc.php) è quasi certo che sei sotto un tentativo di brute force, se invece noti molte url che non esistono (404) è quasi certo sia uno scraper/scanner.
Wordpress è rognoso anche con le pagine 404. Vedendo inoltre la struttura delle tue url “/anno/mese/giorno/titolo” noto che manca il post ID.
Questo significa che se chiamo un post title che non esiste, WP deve comunque fare una query sulla tabella dei post sul titolo, che è un campo varchar, invece che sull’id che è intero e le queries sono molto più veloci. Una struttura migliore di url sarebbe /post-title/postID così nella url resta il titolo che è bello da vedere per l’utente ma WP fa queries sull’ID.
Con questi 2 comandi eventuale traffico anomalo dovrebbe saltare subito all’occhio (ovviamente devi lanciarli nei momenti in cui il sito è lento se il problema è intermittente)
Dopodiche proverei a guardare carico (comando “uptime”) e se la macchina sta swappando (comando “free -m”) questo per verificare che il problema sia proprio sul tuo server e non magari una richiesta bloccante che fa wordpress da un’altra parte.
Se il carico è alto ed il traffico “normale” bisogna andare ad indagare su db (primo passo abilitare lo slow query log) e fare profiling sul codice php (si fa con un estensione php che si chiama xdebug). Controllerei comunque prima traffico e carico. Se hai bisogno di aiuto sono a disposizione e possiamo sentirci per mail per i dettagli.
Grazie, ma ho scelto un approccio drastico: sto migrando a hosting su WordPress.com e mollando il vecchio hosting su Gandi.net.
Visto che stai andando su automattic, del resto se non sono bravi loro ad hostare WordPress siamo messi male :).
Occhio che il nuovo server ha solo il certificato per paoloattivissimo.com e non per attivissimo.me. Anche se fa redirect la verifica del certificato fallisce prima della 301 e sul browser esce sito non sicuro se metto attivissimo.me e non direttamente paoloattivissimo.com.
Devi installare il certificato TLS per attivissimo.me anche sul nuovo server per far andare i redirect
Lo so, ci sto arrivando 🙂
Buongiorno, oggi Chrome (140.0.7339.210, build ufficiale a 64 bit) quando apro questo sito mi consiglia di non aprirlo perché la connessione non è privata.