due chiacchiere

Come non far scattare il qos su Tophost

Seguo il consiglio di Tommy (o forse dovrei dire Davide, dopo la sua recente evoluzione) pubblicando un piccolo accorgimento che ho implementato sul mio blog nei giorni seguenti al cambio di tema. Ma partiamo dall’inizio: quando ci si accinge a rilasciare una nuova veste grafica, è inevitabile che per alcuni giorni i 404 fioccheranno a destra e sinistra, specialmente se sono cambiati i nomi dei fogli di stile, delle immagini e se si usano meccanismi di caching che manterranno i vecchi stili nella pancia del browser dell’utente per molti giorni. Successe così che il mio sito era spesso irraggiungibile perché tutti questi errori facevano innervosire il guardiano di Tophost (altrimenti noto come QoS, qualità del servizio), che ha il compito di garantire un uso delle risorse tra i condomini equo e solidale.

WordPress, nella sua configurazione di base, istruisce il server per chiamare l’interprete PHP sempre, anche quando il file richiesto è un foglio di stile o un’immagine (che non esiste sul server). Da un lato questo ha il vantaggio di mostrare all’utente una pagina 404 carina, dall’altro ha lo svantaggio che 99 volte su 100 si sono usate delle risorse di sistema inutilmente. Così con Tophost abbiamo valutato la situazione, ed alla fine ho trovato una soluzione che dice al server di eseguire l’interprete PHP solo se la risorsa in esame lo richiede.

Esiste un file nella cartella principale del tuo sito, chiamato .htaccess che contiene dei comandi per il server. Se utilizzi WordPress, al suo interno troverai una riga che inizia con <IfModule mod_rewrite.c> e poi una serie di altri comandi. Aggiungi quanto segue subito prima di quella riga:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} \.(css|htm.|js|jpe?g|png|gif)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . / [F]
</IfModule>

Da esperimenti fatti, consiglio di non inserire i comandi all’interno del blocco generato da WordPress (marcato con qualcosa tipo BEGIN WORDPRESS), ma di crearne uno separato. Pare infatti che WordPress non ami che la gente “pasticci” con la sua roba eheh 🙂 Ovviamente questa soluzione non va bene se il tuo sito è in una sottocartella, o se vuoi restituire qualcosa di diverso dall’errore 403 Forbidden a coloro che tentano di accedere una risorsa inesistente sul tuo spazio.

Per vedere se tutto funziona a dovere, ti basta tentare di accedere una pagina sul tuo sito che finisce ad esempio per .css ma non esiste. Prova a fare la stessa cosa qui per vedere cosa succede 🙂

Commenti

  1. Davide Salerno ha detto:

    Un’alternativa sarebbe usare W3 Total Cache ed attivare l’opzione per evitare di gestire gli errori 404 tramite WordPress (o meglio PHP).

    La differenza è che la prima volta che un contenuto genera una pagina 404 questa viene salvata staticamente come file HTML e alle successive richieste di pagina 404 viene fornita quella salvata in cache in precedenza evitando di stare a scomodare WordPress ed avendo nel contempo una pagina 404 più “aggraziata”.

    1. camu ha detto:

      @Davide Salerno: ottima osservazione 😉 Chi non è allergico ai plugin come me, può definitivamente seguire questa strada, anche se non ho mai testato W3 Total Cache su Tophost.

    2. carlo ha detto:

      @Davide Salerno: Peccato che tophost limiti la memoria per gli script a 32Mb e basta mettere due dico due plugin che sei arrivato.

      1. camu ha detto:

        @carlo: ti consiglierei di rivedere le tue convinzioni e di non credere alle leggende metropolitane 🙂 Se dai un’occhiata al codice sorgente di WordPress, scoprirai che è quest’ultimo a limitare la memoria a 32 mega, nel file default-constants.php, non Tophost. La soluzione, comunque, la trovi sempre su questo blog, ed è facile ed indolore.

  2. CyberAngel ha detto:

    Sembra non funzionare, dato che ho appena inviato un commento e la paginetta rossa di TH è scattata… 🙁

    1. camu ha detto:

      @CyberAngel: 🙁 Si, c’è un altro problema in questi giorni… sto subendo un attacco incredibile di spam, tipo 1000 tentativi in un giorno, e tutti gli IP finiscono in una lista nera di htaccess, per bloccarli prima che consumino risorse. Sfortunatamente questi str.nzi a volte usano IP malformati, che il mio plugin comunque scrive nell’htaccess facendo impappinare i server di Tophost 🙁

  3. Davide ha detto:

    Purtroppo a me non ha ancora risolto definitivamente la situazione. Continuo ad ottenere – sporadicamente ma non troppo – l’implacabile errore Blocked by mod_slotlimit. More information about this error may be available in the server error log.
    E tutto questo con un centinaio scarso di visitatori al giorno…

    1. camu ha detto:

      @Davide: il mistero s’infittisce, ed a questo punto non so davvero cosa suggerirti. Qui da me siamo sui 1000 visitatori umani al giorno… che sia un difetto da qualche parte nel foglio di stile?

      1. Davide ha detto:

        @camu: lo temo anch’io: essendo un child theme mi fa forse troppe chiamate con @import. Devo rimetterci le mani… 😉

  4. Davide ha detto:

    (Quanto allo spam, potresti provare Hiddy…

    1. camu ha detto:

      @Davide: sono sempre stato un po’ allergico ai captcha… e comunque non risolverebbero il problema di consumo delle risorse: anche se gli impedisco di commentare, loro possono comunque tentare di caricare la pagina migliaia di volte ogni ora 🙁

      1. Davide ha detto:

        @camu: certo, potrebbero ricaricare la pagina migliaia di volta… Comunque non è un captcha, ma solo un plugin che aggiunge un campo nascosto che solitamente viene riempito in automatico dai bot dello spam (ma non dai veri commentatori, che non lo visualizzano). Risultato: se viene riempito quel campo ingannevole il commento non passa – non va neanche in coda di moderazione né tra lo spam. Non è infallibile, ma abbatte lo spam intercettato da Akismet di almeno il 90%…

        1. camu ha detto:

          @Davide: grazie della precisazione 😀

  5. Mauro ha detto:

    o ancora meglio:

    RewriteCond %{REQUEST_FILENAME} !.(css|htm.|js|jpe?g|png|gif)$

    1. camu ha detto:

      @Mauro: siamo sicuri che con l’OR funzioni allo stesso modo? Se è così provvedo subito a correggere il mio articolo 😀

      1. Mauro ha detto:

        @camu: testato 🙂
        Tra una bestemmia e l’altra, siccome l’FTP di tophost è sotto valium e non accetta l’upload neppure di un htaccess da 900bytes, quindi ho dovuto modificarlo dal cpanel 😐
        Comunque sì, funzia funzia

        1. Davide ha detto:

          @Mauro: se siete sicuri correggo anch’io nuovamente l’htaccess…

        2. camu ha detto:

          @Davide e Mauro: testato anche io, e funziona a dovere. Ho subito provveduto a correggere l’articolo. A dirla tutta sono andato un po’ oltre: ieri ho aggiornato alla beta di WP 3.1, ed a quanto pare WordPress non ama che gli si tocchino le sue regole nell’htaccess (quelle incluse tra BEGIN ed END WordPress), e senza fiatare ha rimosso la mia modifica. Allora invece che modificare quel blocco, ne ho aggiunto uno separato PRIMA, che dovrebbe intercettare le chiamate che non serve far arrivare a WordPress.

        3. Davide ha detto:

          @camu: mannaggia a te, mi stavi facendo impazzire. Hai dimenticato di mettere, nel post, il punto esclamativo prima del backslash nella prima regoletta!

        4. camu ha detto:

          @Davide: no aspetta, come dicevo nel commento qui sopra, queste regole vanno messe FUORI dal blocco di WordPress, ed in quel caso il punto esclamativo non ci vuole. O sbaglio?

        5. Davide ha detto:

          @camu: ho provato a metterle fuori, ma ottenevo errori. Alla fine le ho rimesse dentro il blocco di WordPress (che, da quel che ricordo, riscrive o sovrascrive quel blocco solo se si cambiano le impostazioni dei permalink – quindi forse nel tuo caso è stato per via di un bug della beta…).

        6. camu ha detto:

          @Davide: si, se le metti “dentro”, allora ci vuole il punto esclamativo 🙂

  6. ephestione ha detto:

    Altra correzione (non me ne sono accorto prima):
    RewriteCond %{REQUEST_URI} .(css|s?html?|js|jpe?g|png|gif)$

    1. camu ha detto:

      @ephestione: ma ancora qualcuno usa il prefisso shtml lì fuori? 😀

  7. Paolo ha detto:

    Gentile camu, ho provato a modificare il mio htaccess e tutto sembra funzionare bene in quanto non appena richiedo un file css non esistente mi reindirizza a una pagina di Tophost piuttosto che alla mia pagina 404. Ma non c’è modo di evitare quella simpatica presentazione delle caratteristiche del Topblog? 🙂

    1. camu ha detto:

      @Paolo: stiamo parlando dell’errore 500? 🙂

      1. Paolo ha detto:

        @camu: Nono, una presentazione del pacchetto di Tophost, nessun errore…E’ strano? 🙁

        1. camu ha detto:

          @Paolo: mi fai vedere in privato le stringhe del tuo htaccess? 🙂

        2. Paolo ha detto:

          @camu: C’è posta per te 😀 Grazie per il gentile aiuto 😉

  8. Alx ha detto:

    Ma nel dettaglio cosa fanno quelle istruzioni .htaccess aggiunte?
    è utile anche a prescindere da WordPress?

    1. camu ha detto:

      @Alx: le righe significano semplicemente “se un utente richiede un file con una delle estensioni elencate, e quel file non esiste ( opzione -f ) allora rispondi con un errore 403 invece di invocare WordPress e fargli servire la pagina 404. Questo evita di mettere in moto WP quando non serve (risorsa non esistente).

  9. ak47 ha detto:

    Scusate,

    se wp è installato in una subdir – qualcosa come /wp/ – come posso modificare la regola per Apache affinché funzioni anche in questo caso, IMHO abbastanza diffuso?

    Grazie mille,
    ak47

Lascia un commento