Mi scrive oggi il support di Dreamhost dicendomi che hanno dovuto metter mano al mio db in quanto alcune tabelle (da oltre 116k recond) ne inficiavano le performance.
Il problema pare dipenda da SlimStat, che quindi per un pochino disattiverò.
A seguire la lettera che mi è giunta dal support team.
Hello,
This is just a friendly email to let you know we made a minor change to your “wp” database. It looks like the stats table was not properly indexed, and it was causing a high load when this query was run:# Query_time: 3 Lock_time: 0 Rows_sent: 36 Rows_examined: 116167
[sql]SELECT referer, resource, dt
FROM wp_slim_stats
WHERE referer NOT LIKE ‘%fullo.net%’
AND
referer!=”
ORDER BY dt DESC
LIMIT 0,36;[/sql]
It was having to scan all 116,000 rows in that table to find the referrer. I added this index:
[sql]ALTER TABLE `blog_b2slim_stats` ADD INDEX `referrer` ( `referer` ( 12 ) )[/sql]
And now it scans at most 12 rows! Let us know if you have any other questions. The load has already dropped over 10 points. You should let the program author know of this change so it can help other people not get possibly dinged by their hosting companies!
l’autore è stato ovviamente trackbackato ed avvisato per email dell’accaduto.
ciauz
15 replies on “Qualche problema per SlimStat”
Ciao, il problema effettivamente è noto, e dovrò decidere come risolverlo in un modo o nell’altro. In breve, se aggiungo gli indici (come era in una delle prime versioni), la tabella raddoppia o triplica la sua dimensione. Per siti molto visitati, si arrivava presto ad avere un database di diverse decine di mega. Esempio concreto, il mio db con circa 12.000 righe occupava circa 8 mega con gli indici e meno di 3 mega senza gli indici. Togliendo gli indici, le dimensioni sono diminuite considerevolmente, ma ovviamente rallenta il processo di “ricerca” delle stringhe. Credo che alla fine la soluzione migliore sia lasciare all’utente la possibilità di decidere se usare o meno gli indici, in base alla “capienza” dello spazio che ha per il database.
considera che le mie 100mila righe sono state fatte in circa 1 mese e mezzo di utilizzo di slimstat, il che porta ad un certo problema di ottimizzazione per siti con grossi carichi di lavoro…
capisco che il problema dell’occupazione sia non indifferente ma c’è a contro il fatto che se si ha una perdita di performance di potenza 10 (come detto dal support di dreamhost) ci si ritrova con un blog quasi innavigabile a causa della lentezza del db.
cmq potresti si dare la scelta all’utente ma avvisarlo/forzarlo anche ad usare gli indici se supera un certo numero di entry.
altra cosa che potresti fare è per dati molto vecchi perdere granularità (e quindi righe) aggregandone i valori.
Dunque, una precisazione riguarda la performance. Proprio per ridurre al minimo i tempi di attesa del VISITATORE, ho cercato di ottimizzare in questa direzione tutto il codice. Il rovescio della medaglia è un abbassamento della performance quando si guardano le statistiche nel pannello di amministrazione (uno dei piatti della bilancia deve essere sacrificato). Ma ho ritenuto che qualche “mezzo secondo” in più per chi spulcia le statistiche sia tollerabile, mentre chi naviga il sito non vuole storie: le pagine devo arrivare in fretta. La query segnalata da DreamHost infatti si riferisce ad una richiesta generata dal pannello di controllo. L’idea di avvisarlo è molto buona, e credo che la implementerò presto, insieme ad un pulsante per “accendere o spegnere” gli indici sul database, a seconda delle proprie esigenze. Meno semplice, per come è progettato il DB, è aggregare i valori: dovrei creare una nuova tabella dove memorizzare i contatori… se po’ ffà :) Grazie in ogni caso per il supporto. In questi giorni rilascerò una nuova versione con alcune funzionalità attive, dagli un’occhiata! Un’ultima cosa: che versione usi del plugin? hai eseguito gli aggiornamenti (nel caso usi la 0.8.8)? a presto.
sto usando la 0.8.7 non avendo visto altre segnalazioni sul tuo blog (lo ammetto, non leggo i feed dei commenti ;) )
ho installato la 0.8.9 speriamo vada tutto bene :)
Attualmente non uso WordPress e non conosco nel dettaglio come funzioni questo sistema di statistische, in ogni modo la soluzione è abbastanza semplice dal mio punto di vista. La tabella deve contenere correttamente gli indici, ma i dati “vecchi” (dei mesi e anni precedenti) andrebbero aggregati, eliminando tutte le richieste singole e tenendo traccia solo dei risultati dell’aggregazione. E’ infatti poco utile sapere dopo mesi o anni l’IP dell’utente che in tale giorno a tale ora ha richiesto tale pagina, mentre è invece utile avere un dato aggregato che evidenzi le pagine più richieste, le parole più cercate, etc. etc.
Si mantiene performance e si riduce lo spazio occupato.
questo è vero da un lato, però considera la gestione del “profiling” degli utenti che ti visitano.. tracciare un certo ip all’interno di un lasso di tempo potrebbe farti scoprire che magari quello che si identifica come browser è in realtà un bot che tutti i giorni di sovraccarica di richieste determinate pagine.
Oppure che sei vittima di un trackback spam assault da parte di utenti di aol… ;)
Sì, ma secondo me ti è utile saperlo entro un certo lasso di tempo, non ha molto senso confrontare un IP con uno di 1 anno precedente.
Potresti tenere il mese corrente e quello precedente come dati completi, e gli altri aggregati, per esempio.
Visti gli usuali spazi degli hosting, direi che un indice non dovrebbe constituire un problema, anche se fosse di centinaia di megabyte!
skidx per i dati aggregati dopo un certo periodo hai ragione, e difatti era una delle prime cose che avevo suggerito nei commenti. Però il problema è quando aggregare?
Se ad esempio hai 100 visitatori al giorno e qualche pageview in più è inutile aggregare dopo 1 mese, cmq il carico sul db è ridicolo e ti puoi permettere anche 1 anno..
Se invece hai 10000 visitatori al giorno che producono un 10x di pageview allora per non far schiattare il db (dove attualmente non ci sono indici) l’unica scelta sensata diventa aggregare subito i dati e/o cancellare quelli non rilevanti…
beh, se hai 10 mila utenti al giorno si presume che tu abbia un server in grado di reggerli e uno spazio su disco proporzionato, sennò qualsiasi sistema è inutile. Se hai 10 mila visite ma ti manca lo spazio per tenere una settimana di dati indicizzati, il problema è a monte, mi sa.
Diciamo che il lasso di tempo potrebbe essere deciso dall’utente in base al carico e allo spazio a disposizione, per esempio.
Comunque mi sono sembrati molto professionali quelli di Dreamhost, qualcun altro avrebbe sospeso l’account o l’applicazione direttamente, invece che perder tempo a correggere il problema.
mai parlato di spazio ma di performance/occupazione di CPU… 10000 utenti al gg sono una bazzecola per un server apache+mysql ben configurati… anche una milionata ;)
Ciao a tutti, ho letto con interesse i vari “botta e risposta”, e brevemente aggiungo il mio parere. Il plugin che ho sviluppato non era pensato, all’inizio, per grossi carichi di lavoro. Se avessi un blog con 1 milione di visite al mese, non starei certo su un hosting economico (banda limitata, spazio limitato, potenzialità limitate) ma a quel punto prenderei una macchina tutta mia in housing. E a quel punto invece che wp-slimstat (il mio plugin) userei awstats sui log di apache, ad esempio: molto più performante e sicuramente meno impegnativo per il server. Il plugin che ho fatto è per i blog di medie e piccole dimensioni, che non possono permettersi awstats, e che non hanno abbastanza dimestichezza con la programmazione o la configurazione di software (per installare, che so, php-myvisites). Il plugin richiede ZERO configurazioni e ZERO cambiamenti al template, semplicemente funziona.
Nell’ultima versione, che sto testando prima di rilasciare ufficialmente, comunque sono riuscito a ridurre già di molto l’occupazione del database. Ho stimato (non avendo così tante visite) che per 100.000 righe, il db occupa circa 12 mega (di cui 2 presi dalla tabella che associa IP a Paesi), e ho eliminato i problemi di performance (sperando che non ne vengano fuori altri), anche giocando un po’ con l’EXPLAIN di mysql sulle varie query. Considerando che un blog medio/piccolo ha circa 3000 hits al giorno, si arriva a 90.000 hits al mese, quindi circa 11 mega di occupazione. In un anno sarebbero poco più di 140 mega, che non sono pochi!
Vi ringrazio per l’idea di “perdere granularità”: il database è già concepito per poter memorizzare anche dati accorpati, si tratta ora di tradurre le idee in linee di codice :) In merito al “quando farlo”, io ho pensato ad una soluzione semplice quanto efficace (credo): lo decide l’utente, dalla schermata di configurazione. L’idea è quella di chiedere (come suggerito) all’utente una data, e di compattare tutte le informazioni antecedenti a quella data. Sarà così lui autonomamente a stabilire quando vuole che si perdano le informazioni dettagliate troppo “vecchie”, che ve ne pare.
Sorry se sono stato prolisso, ma volevo spiegare un po’ le varie cose.
Mi sembra la soluzione ottimale, coolmann, che è appunto quella che suggerivo all’inizio.
Comunque oramai Awstats te lo tirano dietro anche su hosting molto economici, roba da 2 euro al mese.
Ciao! In questi giorni mi sono dedicato ad implementare alcune modifiche al mio plugin, ed è ora disponibile la nuova versione 0.9.1 che vi invito a provare (così mi dite se c’è qualche bug che non ho corretto). Riguardo ad Awstats, non è che ce ne siano tanti di hosting che “te lo tirano dietro” per 2 euro al mese. Io meno di 4 euro al mese non sono riuscito a trovare (in italia, perché mi interessa il dominio .it).
La nuova versione, oltre a risolvere problemi delle precedenti, introduce uno switch per attivare o disattivare l’indicizzazione dei campi della tabella che contiene le statistiche, così è l’utente a decidere cosa è meglio per lui. Inoltre è stato completamente automatizzato l’aggiornamento da versioni precedenti. Fatemi sapere che ve ne pare :-)
PS: per pulizia, prima di far attivare al plugin gli indici sulla tabella, vi consiglio di rimuovere indici che avete creato voi a mano con phpmyadmin.