prestazioni

non ho installato captcha ma prima o poi dovrei metterlo.. se lo disabilitassi come si gestisce lo spam?
Statistics invece mi serve per tracciare gli accessi ai nodi e per vedere i nodi più letti.. come faccio ad eliminarlo?
Search invece non è utilizzato

Potete misurare le prestazioni direttamente collegandovi al sito: http://tinyurl.com/64fyh2d
La cosa che mi impensierisce di più sono tutti i processi php rilevati dal monitor di sistema e soprattutto il fatto che edit e inserimenti sono veramente estenuanti.
Purtroppo non posso disabilitare la cache per capire se il problema risiede in quella.

questo l'elenco dei moduli installati:
addthis/
cck/
filefield/
image/
no_anon/
poll/
tracker/
aggregator/
filefield_paths/
imageapi/
node/
print/
translation/
block/
ckeditor/
filter/
imagecache/
profile/
emfield/
fivestar/
imagefield/
page_title/
taxonomy/
update/
jquery_ui/
path/
upload/
contact/
fbconnect/
googlenews/
link/
pathauto/
term_permissions/
user/
boost/
fb_social/
locale/
php/
similar/
throttle/
views/
cache_actions/
date/
menu/
statistics/
token/
votingapi/

Credo che dovrò passare a questa versione, me l'hanno fatta notare anche oggi su drupal.org, non la conoscevo.

Dopo un bel po' di monitorizzazione del sistema infatti mi sono reso conto che il vero problema sta proprio sulle tabelle myisam che vengono bloccate quando si fanno insert e update, ovvero in continuazione vuoi per il modulo statistics vuoi per l'elevato numero di articoli del network. Questo blocca la tabella della cache di boost (che per altro mi pare crei un vero collo di bottiglia nell'architettura passando tutto da li') e quindi le pagine vengono fornite solo quando è unlocked.
Sono solo supposizioni ma credo più o meno stia accadendo questo.

Spero solo questa migrazione sia indolore..

Sono migrato a pressflow e contemporaneamente ho fatto il passaggio da myisam a innodb.
Credo che il vero motivo di miglioramento sia quest'ultimo, però su pressflow devo dire che grazie al fatto che non crea sessioni per gli utenti anonimi, finalmente posso sfruttare i vantaggi del caching con boost.
Mi aspettavo sinceramente dei miglioramenti più netti, ma il fattore di carico è sicuramente migliorato e con 7000 vistatori al giorno, pur rimanendo non troppo veloce, va abbastanza liscio.
Devo però migliorare ulteriormente le prestazioni.

ahahah no, non ha generato grande traffico anche se sotto sesso orale violento ora siamo ben posizionati :D

A parte gli scherzi, ho disabilitato boost e la situazione è decisamente migliorata. Il problema è che non so come reagirà il sistema domani, quando ricominceranno le visite e il traffico regolare.
Devo trovare una soluzione al problema. Evidentemente il problema sono le numerose viste e blocchi che vengono messe in cache e che il sistema rigenera completamente ad ogni inserimento o modifica.

Ciao giovanni, effettivamente ho già lavorato li sopra con yslow.
per le immagini risolverò con una CDN appena avrò tempo. il numero di 404 è dovuto ad alcuni accorgimenti tecnici per personalizzare una pagina rispetto all'altra, ma è in via di risoluzione.
Diciamo che il vero problema non è quello della prestazione di banda (ho appena realizzato un sistema di minifyzzazione di css e js che riduce ulteriormente il peso) che ottimizzo costantemente, ma delle prestazioni della piattaforma drupal, che non appena la tabella di cache di Boost inizia ad ingrandirsi ha dei rallentamenti mostruosi. Al momento è lì il collo di bottiglia (anche se stamattina non si nota perchè ho svuotato la cache

Giovanni ti risolvo ogni dubbio.
Senza boost ho provato solo in orari un po' infelici tipo la notte e va come le palle di cannone, ma ovviamente boost serve a diminuire il numero di query per accesso, quindi essendo il fattore moltiplicativo molto alto (quante ne farà ogni visita: 100? io dico anche di più) rischio di trovarmi un too many mysql connection. Il problema è che boost lavora anch'esso molto sul database e sul disco, quindi all'aumentare della dimensione della cache ho dei tempi di IO wait da panico. Merita che apra una issue sul modulo, ma vedrai che mi orienterò su sistemi di caching esterni.
Il P.R. 0 si spiega bene: siamo online da solo 3 mesi. Quindi è normale sia così basso. Il numero di inbound links è ancora limitato, ma sui motori di ricerca siamo lo stesso messi bene (dimostrazione che il pr conta poco). Su alexa non siamo messi così male: considera che il calcolo del rating è trimestrale e che ogni mese raddoppiamo gli accessi, infatti se vedi il traffic reach per un solo mese i primi tre domini sono tutti in posizioni competitive con i diretti competitor che esistono da anni.
Questa del 301 che mi dici mi giunge nuova. Però mi spiegherei perchè ho spesso problemi con google adwords.
L'hosting è un server dedicato da me gestito senza virtualizzazioni, con php-cgi, apc e apache2 worker, quindi già ottimizzato. Il sito gira su un'unica installazione di (ormai) Pressflow ma senza multisite. Per ovviare alla questione dei domini, dall'url estrae il nome citta che fa da chiave per le viste e quando accedi un nodo controlla che la chiave e la citta assegnata al nodo coincidano, altrimenti in quel caso fa davvero un redirect 301 all'indirizzo giusto. In questo modo ho la separazione totale dei contenuti e non sono accessibili da altre città.
(e per i flash e altre cose ho un adserver residente su un altro server, quindi non appesantiscono, anche se lo devo otttimizzare).
Se hai suggerimenti o curiosità sono tutto orecchie

Per palle di cannone intendevo veloce.
Ho provato a disattivare Boost, almeno finchè non risolvo o capisco tutta una serie di problemi connessi. Quindi ora vi dico la differenza di prestazioni.
Sicuramente una serie di ottimizzazioni che piacevano a Yslow scompaiono

Gli errori dovevano essere plurimi nel senso che mi sono reso conto che evidentemente prima a fronte di una generazione della cache, poi gli utenti non accedevano alle pagine in cache. Me ne sono accorto perchè adesso i valori dei contatori di accessi sono sballati, nel senso che non tracciano quasi più nulla, comportamento che mi sembra in linea con boost e che invece prima non rilevavo (gli accessi ai nodi erano ben tracciati, quindi la gente accedeva a drupal e non alla cache).
Detto questo, cosa ho fatto?
Sono andato per gradi.
Innanzitutto come scritto ho disabilitato Boost e fatto un truncate delle sue popolosissime tabelle.
Dopo di che ho disattivato la cache del core e riabilitato boost con queste due opzioni modificate:
-Check database timestamps for any site changes. Only if there has been a change will boost flush the expired content on cron
-rimozione della compressione gzip (tanto ho il mod_deflate di apache)
Ho pure aggiunto il modulo rules e ho fatto si che ad ogni modifica e nuovo inserimento faccia girare il cron per tenerlo aggiornato.

Adesso come potete notare le prestazioni sono veramente ottime, evidentemente o Boost andava in conflitto con la Core Cache (settata su normale non su aggressiva.. ora è disabled) oppure per qualche assurdo motivo generava la cache delle pagine ma alla fine della loro lifetime non veniva rigenerata, vanificando di fatto dopo 10 minuti il fatto di avere Boost. Tutto questo continuando ad aumentare i record nel DB.. ora quello che voglio monitorare è la crescita delle tabelle di cache, perchè oltre certe cifre compromette le prestazioni.

Mi rimane il cruccio di Yslow, che continua a segnare una C, a fronte di prestazioni del tutto performanti e che se disabilito Boost mi promuove a B..

@Ziobudda (ma ce l'hai ancora il sito ziobudda? ricordo che ai tempi dei tempi era una delle mie mete virtuali preferite):
prima di iniziare a smanettare pesantemente il server voglio essere sicuro che la piattaforma software sia al massimo delle sue possibilità, altrimenti rischio di trascinarmi dietro problemi su problemi. Mod_deflate e mod_expires dovrebbero bastare per quelle funzioni di cui parli.
Sicuramente i prossimi passaggi lato sistema saranno nginx e lighttpd per le statiche, memcache e varnish. Prima però voglio capire questo sistema quanto stress può sopportare.

Grazie a tutti per le risposte, questo thread sta approfondendo diverse tematiche interessanti

EDIT: * noto che nelle ultime ore l'attività di caching di boost ha ricominciato a funzionare a fasi alterne.. alcuni degli ultimi articoli non sono in cache. non capisco il motivo

azz... è quello in locale.. da dove vi è saltato fuori?

quello che non capisco è dove compaiono quegli indirizzi (che sono quelli che uso per lo sviluppo in locale) e su cosa vi arrivano i gateway time out.
I minify non prendono il punteggio massimo di Yslow per colpa di alcuni js esterni sui quali non ho controllo (facebook e piattaforma di adv).
Anche secondo me Boost non è ben configurato, perchè la cache funziona a volte si e a volte no

No infatti.. ma ormai mi sono incaponito che voglio questa cache funzionante. La velocità con cui forniamo i contenuti è uno dei fattori determinanti per siti d'informazione con grande concorrenza

ho definitivamente tolto boost. Guardate con i vostri occhi la differenza.
Evidentemente c'è qualcosa ne sito che non lo fa funzionare a dovere, non ho altre spiegazioni

Ti ringrazio per i complimenti. Scegliere Drupal è stata una scommessa. Per progetti grandi (al momento Perugia sta macinando più di tutti e Roma cresce a vista d'occhio.. stanno arrivando altre 4 redazioni) di solito opto per piattaforme scritte da me.
Per quanto riguarda Boost credo che aprirò una issue. E' davvero assurdo che rallenti (vi devo far vedere i grafici del server che differenza). Comunque la colpa potrebbe essere dovuta ai molti domini, perchè lui rigenera pagine statiche di tutti i contenuti per tutti i domini.. quindi in cache su perugia in realtà esistono anche gli articoli di prato, anche se poi con i redirect non ci si può accedere che sotto il dominio corretto. Non vedo altre spiegazioni.
Anche facebook social ha dei problemi sulla condivisone dalla homepage. Ma è l'ultima delle priorità al momento