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:
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:
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
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!
#1MiCc83
Il cambiamento si nota… e parecchio! Grazie per la guida, sperando un giorno di poterne fare uso!
#2lorenzone92
Grazie per la guida! 🙂
#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
#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!
#5paoloc
Il cambiamento è “palpabile”. Complimenti a k76 e shor.
#6k76
@lorenzone92 su wp2.3 non esiste la tabella categories
vai pure con gli altri 3 indici
@paoloc grazie
#7senzastile
Ottimo lavoro, e ottima quida Shor!
#8Shor
@paoloc: grazie 🙂
@senzastile: we bello grazie, ma questa guida è opera del mitico K76 🙂
#9k76
più che mitico direi mitologico… col corpo d’umano e la testa di c##zo 🙂
grazie cmq
#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!! 😀
#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.
#12Maio
Sempre bravo Shor…:)
#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à
#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.
#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 🙂
#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
#17ellogallo
Si nota il miglioramento, soprattutto considerando i numeri dei contatti che hai!
#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è?!?!
#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
#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.
#21Joss
Ayeh! non da più problemi adesso che il tag cloud non c’è più.
#22k76
uhhhhhh
vedi mo!
Grandioso.
@Nguulo mbhè quello è un’intervento massiccio, volevo evitare mettendo mano solo a quello che c’è
#23Angelo
e per snellire il tutto…..fate caricare 4 o 5 articoli…non 10000 😉
#24Shor
Tolta, e poi non dite che non ascolto i miei lettori 😉
#25Sleeping
Un po’ fuori dalla mia capacità di comprensione, ma molto interessante 🙂
#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
#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
#28sarah
salve, il ns server è presso un provider ma non lo gestiamo direttamente; possiamo inviare questa analisi al loro webmaster ?
#29Giorgio
io credo che togliendo apache e mettendo lighttpd risolverete anche gli altri problemi 🙂
#30StromLem
[url=https://stromectolgf.com/#]stromectol 3 mg tablets price[/url] stromectol 3mg
#31MichealGlach
[url=https://gabapentin.icu/#]brand neurontin 100 mg canada[/url] neurontin prescription cost
#32MichealGlach
[url=https://erectionpills.best/#]otc ed pills[/url] herbal ed treatment
#33MichealGlach
[url=https://cipro.best/#]buy cipro cheap[/url] cipro for sale
#34Robertonok
[url=https://stromectoltrust.com/#]stromectol 3mg tablets[/url] stromectol 12 mg tablets
#35KeithGlove
[url=https://erectionpills.shop/#]non prescription ed pills[/url] erection pills online