Geekissimo

Guida su come ottimizzare WordPress per i blog ad alto traffico

 
Shor (Angelo Di Veroli)
16 Ottobre 2007
29 commenti

WordPress è una piattaforma ottima per quel che riguarda la gestione e la pubblicazione dei post. Si adatta a tutto in vitù anche del fatto che esiste una comunità di sviluppatori enorme, chi sviluppa plugins e chi i temi. Purtroppo, nonostante la sua enorme diffusione, rimane un grosso problema di fondo, è un divoratore di risorse, e di fatto quando un blog creato in questa piattaforma supera i 100 utenti contemporanei cominciano i primi dolori e i primi problemi sono relativi a MySql.

La prima cosa da fare per evitare una crisi di MySql è quella di implementare un po’ di page caching così diminuisce il numero di volte il motore di WP vada ad accedere ai dati reali. Così il vostro server non deve elaborare pagine php e mysql non deve interrogare il DB. Non si tratta di avere dati sempre vecchi ma si può raggiungere un ragionevole compromesso tra offline ed online. Per fortuna Riccardo Galli ha pensato e sviluppato un plugin che ci evita la fatica di andare a perdere ore ed ore nella configurazione di apache, stiamo parlando del plugin WP-Cache, si istalla come un normalissimo plugin ed ha alcuni parametri di configurazione nella sezione Options.

Una volta installata questa plugin bisogna attivarla ed andando nella pagina di configurazione andiamo a cambiare 1 parametro soltanto: Expire time (in seconds) lo impostiamo a 240 secondi (4 minuti) così che le nostre pagine non siamo nè troppo vecchie nè create all’istante. Possiamo monitorare l’andamento della cache con i 2 parametri che compaiono in fondo alla pagina di configurazione. Solitamente per un sito con 200-300 utenti contemporanei (parliamo di un sito molto esteso) le pagine in cache si attestano attorno alle 400-500, dipende molto da quante persone richiedono la stessa pagina.

Già solo con quest’operazione si abbattono i consumi di CPU del 20-30% ma a volte non bastano, dobbiamo scendere di un paio di livelli per ottimizzare al meglio le prestazioni del nostro database. Un database è buono quando è progettato bene! Non posso dire che il DB di WordPress sia ottimo, ma con alcuni accorgimenti si può migliorare senza andare a toccare il codice sorgente di WP e per fortuna esistono molti plugin che ci aiutano a mantenere “pulito” il nostro DB.

Ottimizzare il DB per tutte quelle tabelle che vanno in “OverHead” (in eccedenza) è importante perchè in questo modo il nostro database non cresce a dismisura, soprattutto per quei blog che hanno molti post e molti commenti, attenzione che però l’operazione di ottimizzazione alle volta fa crashare il DB, conviene sempre fare prima un Backup. Esiste un plugin che fa solo l’ottimizzazione del DB si chiama OptimizeDB analizza e con un singolo tasto “optimize now” fa tutta l’operazione per voi. Per i più smanettoni ed esperti di Mysql c’è il plugin Wp-phpmyadmin che vi mette a disposizione tutta la potenza di PhpMyAdmin.

Nel caso di Geekissimo purtroppo tutte queste operazioni non sono bastate, di fatto la RAM occupata è rimasta alta , 3,5 Gb occupati su 4 Gb e le CPu erano largamente occupate dal processo di MySql, che ad ogni singolo accesso prendeva un 0,9% della CPU toccando così punte del 270%-300%, ottenendo un rallentamento generale. A questo punto l’unica cosa da fare è quella di metter mano al Database, prima a livello di creazione di indici (WP ne è esente) e poi a livello di database lato server. Armiamoci di razionalità e pazienza.


Creazione di indici aggiuntivi:
Il primo indice che manca a tutti gli effetti è sulla tabella options che viene utilizzata per trovare tutti i record che hanno autoload.
perciò andiamo a creare l’indice in questione con questa query SQL:

create index idx_options_autoload on wp_options (autoload);

Un altro indice da creare quello relativo alle categorie, di fatto ne esiste uno sul campo category_nicename, siccome male non fa, noi ne creiamo uno su category_name

create unique index idx_cat_name on wp_categories (cat_name);

Ora veniamo all’indice più importante, quello dei posts, infatti per ogni pagina viene interrogata la data del post per vedere se è visualizzabile o meno.
Per facilitare il compito a MySql basta creare 2 indici, uno sul campo date ed uno sul campo date_gmt:

create index idx_post_date_gmt on wp_posts (post_date_gmt);
create index idx_post_date on wp_posts (post_date);

Con gli indici abbiamo finito, a questo punto MySql ha cambiato atteggiamento, è diventato un po’ più agile, ma ancora una volta a geekissimo non basta! Resta di fatto molto importante che MySql mantenga una dimensione accettabile e che non utilizzi mai la partizione di swap, in caso contrario dobbiamo inevitabilmente metter mano alla configurazione del server, perciò dobbiamo limitare l’utilizzo di ram.

Dobbiamo scendere a livello server e impostare alcuni parametri nel file my.cnf che solitamente si trova in /etc/my.cnf. Questo file configura le variabili di ambiente del nostro database, dobbiamo fare in modo che accetti molte connessioni contemporanee e che faccia query solo quando una query non è già stata fatta (qcache). Il numero massimo di connessioni contemporanee su MySql di default (se non specificato) è impostato a 100, andiamo ad aumentarlo, impostiamolo a 500.

Alcuni altri parametri tipo i thread vanno misurati e configurati a seconda del server, dell’hardware a disposizione e del numero di accessi simultanei per il blog in questione.
Dopo un po’ di prove di performance e di stress ho raggiunto questa configurazione che va bene un po’ per tutti quei server che hanno intenso traffico:

[mysqld]
safe-show-database
skip-innodb
max_connections = 500
key_buffer = 32M
myisam_sort_buffer_size = 64M
join_buffer_size = 1M
read_buffer_size = 1M
sort_buffer_size = 2M
table_cache = 1800
thread_cache_size = 384
wait_timeout = 35
connect_timeout = 10
tmp_table_size = 64M
max_heap_table_size = 64M
max_allowed_packet = 64M
max_connect_errors = 10
thread_concurrency = 2
read_rnd_buffer_size = 524288
bulk_insert_buffer_size = 8M
query_cache_limit = 3M
query_cache_size = 64M
query_cache_type = 1
query_prealloc_size = 163840
query_alloc_block_size = 32768
default-storage-engine = MyISAM

[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

Rinominiamo quindi il file my.cnf in my.cnf.old e creiamone uno nuovo con la configurazione di cui sopra. A questo punto non ci resta altro che riavviare il server mysql con un /etc/init.d/mysql restart (nel caso di geekissimo) e goderci lo spettacolo! Ora geekissimo viaggia con 1.7 Gb occupati su 4 totali mentre l’utilizzo della CPU si attesta tra il 4% ed il 150% in momenti di intenso traffico.

Per maggiori informazioni su quali parametri utilizzare per ottimizzare MySql seguite la guida ufficiale di MySql. Resta da ottimizzare Apache ma questo spero lo faremo un altro giorno!

Ringrazio di cuore K76 per avermi aiutato a risolvere i problemi che ormai affliggevano Geekissimo da quasi una settimana. Grazie a lui anche per questa splendida guida originale scritta e messa in pratica apposta per Geekissimo. Grazie ancora!
Potrebbe interessarti anche
Articoli Correlati
Come utilizzare lo stile capolettera in blog e siti web

Come utilizzare lo stile capolettera in blog e siti web

Come è noto (e non bisogna certo essere dei geek per saperlo), così come nel resto della nostra società, anche nel mondo del web l’occhio vuole la sua parte. Di […]

Cosa fare prima di aggiornare WordPress

Cosa fare prima di aggiornare WordPress

Croce e delizia di ogni blogger, gli aggiornamenti di WordPress sono sempre un importante passo da compiere per chiunque gestisca un blog basato proprio sulla ormai celeberrima piattaforma open source. […]

Blog WordPress, come utilizzare una home page diversa da quella predefinita

Blog WordPress, come utilizzare una home page diversa da quella predefinita

Da bravi geek avrete sicuramente notato che le home page dei milioni di blog presenti sul web sono quasi tutte impostate nello stesso modo: l’elenco degli articoli più recenti comparsi […]

Blog WordPress, come separare i commenti dai trackback

Blog WordPress, come separare i commenti dai trackback

Ed ecco che anche oggi torniamo a dare una mano a tutti coloro che, per un motivo o l’altro, hanno deciso di aprire un blog utilizzando come piattaforma l’ottimo WordPress […]

Metti il turbo al tuo blog WordPress con PHPSpeedy

Metti il turbo al tuo blog WordPress con PHPSpeedy

Leon Chevalier ha appena rilasciato un interessante script gratuito che permetterà di ridurre il tempo di caricamento del vostro sito o blog. PHPSpeedy riduce le richieste HTTP e comprime i […]

Lista Commenti
Aggiungi il tuo commento

Fai Login oppure Iscriviti: è gratis e bastano pochi secondi.

Nome*
E-mail**
Sito Web
* richiesto
** richiesta, ma non sarà pubblicata
Commento

  • #1MiCc83

    Il cambiamento si nota… e parecchio! Grazie per la guida, sperando un giorno di poterne fare uso!

    16 Ott 2007, 3:02 pm Rispondi|Quota
  • #2lorenzone92

    Grazie per la guida! 🙂

    16 Ott 2007, 3:11 pm Rispondi|Quota
  • #3k76

    eh grazie a voi
    speravo di essere di utile 🙂
    i vostri ringraziamenti vanno girati ovviamente anche a Shor che m’ha dato la possibilità di “spippolarci” su

    16 Ott 2007, 3:26 pm Rispondi|Quota
  • #4lorenzone92

    Quando vado ad eseguire la query:
    create unique index idx_cat_name on wp_categories (cat_name);

    ricevo un errore perché non esiste la tabella wp_categories; uso WP 2.3!

    16 Ott 2007, 3:34 pm Rispondi|Quota
  • #5paoloc

    Il cambiamento è “palpabile”. Complimenti a k76 e shor.

    16 Ott 2007, 3:46 pm Rispondi|Quota
  • #6k76

    @lorenzone92 su wp2.3 non esiste la tabella categories
    vai pure con gli altri 3 indici

    @paoloc grazie

    16 Ott 2007, 4:00 pm Rispondi|Quota
  • #7senzastile

    Ottimo lavoro, e ottima quida Shor!

    16 Ott 2007, 4:08 pm Rispondi|Quota
  • #8Shor

    @paoloc: grazie 🙂

    @senzastile: we bello grazie, ma questa guida è opera del mitico K76 🙂

    16 Ott 2007, 4:12 pm Rispondi|Quota
  • #9k76

    più che mitico direi mitologico… col corpo d’umano e la testa di c##zo 🙂

    grazie cmq

    16 Ott 2007, 5:36 pm Rispondi|Quota
  • #10Teo Ambrogio

    davvero un’ottima cosa.. almeno l’idea è quella… mi son ritrovato spesse volte a lavorare con la cache lanciando vari thread per velocizzare l’enorme flusso di comunicazione… il linguaggio e la tecnologia erano complet diversi (.net e c# con sqlserver) ma lo spirito è quello… e funzionava!! 😀

    16 Ott 2007, 6:09 pm Rispondi|Quota
  • #11k76

    infatti teo, si usa un po’ ovunque la cache
    si potrebbe ottimizzare ulteriormente, a livello di php però per ora vediamo come funge con queste modifiche.
    Volevo evitare di intervenire direttamente server-side.

    16 Ott 2007, 6:21 pm Rispondi|Quota
  • #12Maio

    Sempre bravo Shor…:)

    16 Ott 2007, 8:59 pm Rispondi|Quota
  • #13Davide Salerno

    Io ho un problema assurdo con Wp-cache che non riesco a risolvere: in pratica una volta attivato solo con l’attuale tema che ho non mi refresha la pagina dei singoli post quando qualcuno invia un nuovo commento e quindi quest’ultimo non compare.

    Una cosa veramente assurda che mi sta facendo impazzire.

    Comunque ottima guida e complimenti a K76. Volendo si potrebbe aggiungere qualcosa sull’ottimizzazione del tema che mi sembra manca e fa recuperare ancora un pò di velocità

    16 Ott 2007, 11:07 pm Rispondi|Quota
  • #14Gianluca

    Ciao sono l’Amministratore del ForumDirectory. Stò selezionando una serie di blog e vorrei comunicarti che ho inserito il tuo blog personale nella categoria Internet sezione Blog. Se desideri potrai vedere la recensione cliccando nel link quà sotto. Spero che la recensione sia stata di tuo gradimento ciao.

    http://www.gcsoftwares.com/forumdirectory/viewtopic.php?t=4&start=30

    http://www.gcsoftwares.com

    PS: Sul sito ci sono alcune risorse utili da scaricare.

    17 Ott 2007, 1:29 am Rispondi|Quota
  • #15ArcheoIT

    Beh che dire… grazie! Ho avuto problemi con Wp-cache e ho dovuto disinstallare il plug-in anche se penso che fossero problemi risolvibili. La cosa davvero utile, alla quale non pensavo, è stato il suggerimento di mettere mano al database di WP. La creazione degli indici ha decisamente snellito l’accesso al DB… quando passerò su dedicato terrò conto senz’altro dei suggerimenti per la configurazione di mysql. Intanto bookmarko il tuo post 🙂

    17 Ott 2007, 1:32 am Rispondi|Quota
  • #16Francesco Giossi

    da quando è stato ottimizzato, il sito non è più raggiungibile con IE7 almeno due volte su tre! (da due macchine diverse).
    Scarica tutta la hp, poi alla fine da un bel messaggio di errore e tutto magicamente scompare (impossibile visualizzare la pagina).
    Se uso la stessa finestra di IE e ricarico, allora tutto è ok, ma se apro una nuova sessione l’errore si ripresenta.
    Il mio sospetto è che possa essere quell’orrendo widget per il tag cloud che fa crashare IE (ma perchè l’hai messo lo sa il cielo, fa veramente schifo :p) e non centri una beata fava l’ottimizzazione del database.
    ora sto usando firefox e non da problemi

    17 Ott 2007, 11:02 am Rispondi|Quota
  • #17ellogallo

    Si nota il miglioramento, soprattutto considerando i numeri dei contatti che hai!

    17 Ott 2007, 11:23 am Rispondi|Quota
  • #18k76

    @Davide per il tuo problema dei posts sul forum di wordpress ci sono un sacco di discussione sul quel tipo di problema, dipende dalla versione di PHP installata sul server

    @ArcheoIT mi fa piacere, se hai bisogno sai benissimo dove trovarci

    @Francesco uhhhh questo si che è un problema… ne parlo con shor! Pazzesco WP a volte!

    @ElloGallo ottimo nè?!?!

    17 Ott 2007, 12:21 pm Rispondi|Quota
  • #19Nguulo

    Se puoi ricompila mettendo i giusti CFLAGS e strippa.
    http://httpd.apache.org/docs/1.3/misc/perf-tuning.html

    Binda il webserver su una porta diversa dalla 80 e metti un reverse proxy tipo squid.

    Sistema il problema del FIN_WAIT2 e setta alcuni parametri del tcp con sysctl tipo:
    http://www.acc.umu.se/~maswan/linux-netperf.txt

    Se puoi fai servire le immagini da lighttpd (http://www.lighttpd.net/)

    hdparm per ottimizzare il disco.

    Boh io faccio così, se serve fai un fischio

    17 Ott 2007, 2:24 pm Rispondi|Quota
  • #20Francesco Giossi

    Credo sia il tag cloud che “sminchia” il browser.

    Di fatto è uno script che viene scaricato da http://acnetwork.flux.acsyndication.com/AdServer/

    e si impasta alla riga 285.
    Non ho idea di cosa sia.
    Fatto sta che messo sotto un debugger, IE entra in loop sulla istruzione

    elemToShowR6376R[key].showatupdate(p);

    ovviamente non sto qui a debuggarla perchè non ne ho il tempo, ma fatto sta che anche in questo caso non si riesce a vedere una ceppa di niente.

    17 Ott 2007, 2:55 pm Rispondi|Quota
  • #21Joss

    Ayeh! non da più problemi adesso che il tag cloud non c’è più.

    17 Ott 2007, 4:53 pm Rispondi|Quota
  • #22k76

    uhhhhhh
    vedi mo!
    Grandioso.

    @Nguulo mbhè quello è un’intervento massiccio, volevo evitare mettendo mano solo a quello che c’è

    17 Ott 2007, 5:00 pm Rispondi|Quota
  • #23Angelo

    e per snellire il tutto…..fate caricare 4 o 5 articoli…non 10000 😉

    17 Ott 2007, 5:03 pm Rispondi|Quota
  • #24Shor

    Tolta, e poi non dite che non ascolto i miei lettori 😉

    17 Ott 2007, 5:07 pm Rispondi|Quota
  • #25Sleeping

    Un po’ fuori dalla mia capacità di comprensione, ma molto interessante 🙂

    17 Ott 2007, 5:18 pm Rispondi|Quota
  • #26Aleko

    Visto che hai un server tutto tuo, userei squid anzichè wp-cache. Complimenti per la guida! Giusto per evitarmi test stressanti, qual’è la tua configurazione hardware relazionata al file di configurazione mysql ??

    Grazie anticipatamente per l’attenzione

    18 Ott 2007, 3:42 pm Rispondi|Quota
  • #27k76

    Certo Squid come reverse proxy, non sarebbe male ma in 2 minuti wp-cache è stato installato e abilitato
    Lo diceva anche Nguulo e come detto a lui, la soluzione che cercavamo era qualcosa di più semplice senza dover installare nuovi SW sul srv.

    4 Gb di RAM – 4 Xeon 2.4 GHz – HDD 120 Gb

    18 Ott 2007, 3:49 pm Rispondi|Quota
  • #28sarah

    salve, il ns server è presso un provider ma non lo gestiamo direttamente; possiamo inviare questa analisi al loro webmaster ?

    13 Giu 2009, 8:32 pm Rispondi|Quota
  • #29Giorgio

    io credo che togliendo apache e mettendo lighttpd risolverete anche gli altri problemi 🙂

    5 Giu 2010, 8:38 am Rispondi|Quota