Il tuo server subisce dei rallentamenti ? Se tu come me sei un piccolo publisher indipendente, capirai che perdere una fetta consistente di traffico online a causa di problemi con il server può essere davvero frustrante.

Se il tuo servizio di statistiche online in tempo reale mostra delle flessioni improvvise ed una media di visitatori non consueta a certe ore del giorno, di sicuro c'è qualcosa che non va sul tuo server.


Photo credit: Linda Bucklin

Per capire quello che sta succedendo, ci vuole l'abilità e la pazienza di un webmaster capace che ha abbastanza perseveranza per scoprire gli spider web nascosti nel tuo sito. Scoprire qual è la causa non è facile, soprattutto quando le cause possono essere multiple.

Questo è quello che mi è accaduto negli ultimi 6 mesi.

Anche se questo mostrerà alcune nostre mancanze, non mi vergogno di condividere la mia storia e spero che possa aiutare altri publisher online come me a non perdere tempo, risorse e denaro.

Ho iniziato a notare delle flessioni improvvise di traffico sul mio sito principale www.masternewmedia.org alcuni mesi fa, e nonostante il traffico mensile crescesse, non ho potuto fare a meno di notare queste flessioni improvvise e cercare di capire quali fossero i motivi.

Insieme con il mio webmaster Drazen D., abbiamo iniziato a focalizzarci su Movable Type che è la nostra piattaforma di publishing personale che usiamo per mantenere tutti i nostri siti Web. Abbiamo pensato dapprima che la causa fosse il processo di upload e ci siamo concentrati sulla ricostruzione dei template della pagina in modo da rendere più snello il processo di caricamento sul server ogni volta che il server avesse avuto il bisogno di fare il rebuild di una o più pagine.

Abbiamo pensato che il server venisse rallentato nel momento in cui si pubblicava un nuovo articolo, dal momento che il sistema di publishing, quando pubblica l'articolo, aggiorna tutto l'archivio, le pagine di categorie e le pagine di tag, con le quali tagghiamo il contenuto di ciascun articolo.
Dopo aver aggiustato tutto questo sistema di publishing, ci siamo accorti che i problemi sul server non accennavano a diminuire.


Le flessioni improvvise di traffico sono sintomi di un comportamento anormale. Se accadono di frequente ci sono problemi sicuri dal lato server.

Raccomando a chiunque sia nella mia posizione di guardare con serietà all'architettura del template di pagina (il mio è stato il risultato di una serie di patch che hanno portato più danni che benefici). Comunque il traffico sul sito, l'accesso alle pagine, ed anche la conseguente abilità degli utenti di avere un'esperienza positiva del sito erano stati compromessi. Le flessioni nel traffico dovute a problemi sul server si riflettevano nei guadagni di adsense poiché meno persone accedevano alle pagine, meno erano coloro che, trovando una pubblicità contestuale di loro interesse, ci cliccavano.

Altri due elementi che rallentavano il server erano sicuramente "commenti e trackback" spam che, utilizzati da marketer senza scrupolo, finiscono per rallentare il server.

La cosa più assurda è il fatto che questi commenti e trackback spam sono spesso manovrati da bot automatici che annegano il tuo sito con link a siti illegali ad una velocità di centinaia di link all'ora.

Per molte persone gestire questi dispositivi tramite filtri antispam diventa difficoltoso e in molti preferiscono bloccare queste funzionalità così importanti per i feedback e le conversazioni su di un argomento.

Questo problema che rallentava la velocità del server fortunatamente è stato risolto o almeno limitato anche se in un modo sbagliato, cioè bloccandolo senza avvertire i lettori.

Ma nonostante questo, le flessioni di traffico continuavano a manifestarsi.

Qui è come appare il traffico sul sito quando il server aziendale fa il suo lavoro.

Non sto dicendo che tutto il lavoro che era stato fatto sui template e sui commenti/trackback spam non avesse portato a dei risultati positivi, tutt'altro, ma ad ore specifiche il nostro server dedicato (su Pair.com a Pittsburgh) continuava a manifestare problemi di cui non riuscivamo ad identificare la causa.
Quindi abbiamo continuato la nostra indagine e siamo passati ai feed RSS. Io faccio largo uso degli RSS e aggrego molti contenuti dai siti che gestisco. Dovevamo trovare un modo per alleggerire l'aggregazione RSS, il parsing e l'output affinchè il nostro server dedicato non ne risentisse.
Utilizzare un service provider esterno (o un secondo server dedicato con un software di newsmastering personalizzato come forniscono MySyndicaat e Newsgator) ci ha aiutato significativamente e abbiamo notato dei discreti miglioramenti nel momento in cui abbiamo abbandonato il motore di newsmastering Carp che funzionava sul nostro server aziendale.

L'RSS caching è un altro importante passo da fare che aiuta a ridurre il consumo di banda generale e il caricamento del server. Con l'RSS caching immagazzini il contenuto del feed ad una certa ora permettendo alla pagina di caricarsi in maniera più veloce con una maggiore efficienza di banda.

Ma purtroppo il problema al server non riguardava gli RSS.

Quindi abbiamo iniziato a monitorare il server dedicato ancora più attentamente cercando di identificare gli script esatti coinvolti, i cron jobs e i compiti che venivano effettuati dal server quando le statistiche scendevano.

Drazen ha scoperto cron jobs che non avevano il bisogno di esistere, e script sconosciuti messi da qualcuno nel passato o piazzati formalmente dall' internet provider. Li abbiamo tutti sospesi, cancellati o rimossi.

Ma neanche questo aveva risolto i problemi di rallentamento del server.
A questo punto abbiamo capito che stavamo guardando semplicemente nel posto sbagliato.

Il problema non era sul server!

Il problema riguardava un utente !

Un utente ?

Si un utente. Questa è la sua immagine:

Come immagino MSNbot, il crawler/spider di siti che può mettere in difficoltà il tuo server, se non gestisci il tuo file robotx.txt in maniera appropriata - Photo credit: Michael Osterrieder

MSNbot è un web spider che visita il tuo sito ed ogni collegamento ipertestuale presente così come i crawler Google o Yahoo. La sua funzione è indicizzare il contenuto del tuo sito sul motore di ricerca MSN e sui servizi ad esso correlati.

Putroppo MSNbot è apparentemente meno cortese e discreto degli spider degli altri motori di ricerca. Secondo una mia piccola ricerca riguardo a questo argomento, MSNbot è vulnerabile ad una situazione come la mia, in cui un sito di poche migliaia di pagine pubblica liste di feed RSS di categorie di articoli e siti.

"Vi raccomandiamo di guardare con attenzione MSNBOT e di tener traccia di quante richieste simultanee fa al server. Il risultato può essere un'attività che assomiglia ad un attacco denial of service."

(fonte: Spidertrack - 20 settembre 2004)

e

"Qui una lista incompleta delle cose che MSNBot fa di routine su questo sito.

Tutti questi azioni non sono desiderate...."

(fonte: Banning MSNBot: an open letter to MSN Search - Chris Siebenmann - 14 novembre 2005)

Se fai una ricerca approfondita su Google, ti accorgerai che non si tratta di una storia nuova e ci sono vari commenti di webmaster e publisher che hanno affrontato gli stessi problemi, problemi che continuano ancora adesso.

Ma allora cosa fare con MSNbot?

Devi saper gestire il tuo file robots.txt in maniera intelligente. Questo file di testo che è piazzato sul tuo server, informa gli spider dei motori di ricerca, come MSNbot, delle regole da seguire per effettuare lo spidering del tuo sito. Puoi infatti bannare spider specifici, limitare il loro accesso e controllare quali pagine desideri far indicizzare.

Impara come gestire il file Robots.txt su Wikipedia.

Canale ufficiale

Cosa Microsoft suggerisce di fare:
http://g.msn.com/0HEMSN_SEARCH...

Approfondisci quello che altre persone hanno scoperto:

Bots, Spiders and Bandwidth
5 gennaio 2006

MSNbot - information
23 marzo 2005

Slow down...
12 settembre 2005

Banning MSNBot: an open letter to MSN Search
14 novembre 2005

HOW-TO block the most common bad bots using robots.txt
26 aprile 2006