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 scritto:

    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”.

    Risposte al commento di Davide Salerno

    1. camu
      ha scritto:

      @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 scritto:

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

      Risposte al commento di carlo

      1. camu
        ha scritto:

        @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 scritto:

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

    Risposte al commento di CyberAngel

    1. camu
      ha scritto:

      @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 scritto:

    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…

    Risposte al commento di Davide

    1. camu
      ha scritto:

      @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?

      Risposte al commento di camu

      1. Davide
        ha scritto:

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

  4. Davide
    ha scritto:

    (Quanto allo spam, potresti provare Hiddy…

    Risposte al commento di Davide

    1. camu
      ha scritto:

      @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 πŸ™

      Risposte al commento di camu

      1. Davide
        ha scritto:

        @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%…

        Risposte al commento di Davide
        1. camu
          ha scritto:

          @Davide: grazie della precisazione πŸ˜€

  5. Mauro
    ha scritto:

    o ancora meglio:

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

    Risposte al commento di Mauro

    1. camu
      ha scritto:

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

      Risposte al commento di camu

      1. Mauro
        ha scritto:

        @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

        Risposte al commento di Mauro
        1. Davide
          ha scritto:

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

          Risposte al commento di Davide
        2. camu
          ha scritto:

          @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.

          Risposte al commento di camu
        3. Davide
          ha scritto:

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

          Risposte al commento di Davide
        4. camu
          ha scritto:

          @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?

          Risposte al commento di camu
        5. Davide
          ha scritto:

          @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…).

          Risposte al commento di Davide
        6. camu
          ha scritto:

          @Davide: si, se le metti “dentro”, allora ci vuole il punto esclamativo πŸ™‚

  6. ephestione
    ha scritto:

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

    Risposte al commento di ephestione

    1. camu
      ha scritto:

      @ephestione: ma ancora qualcuno usa il prefisso shtml lì fuori? πŸ˜€

  7. Paolo
    ha scritto:

    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? πŸ™‚

    Risposte al commento di Paolo

    1. camu
      ha scritto:

      @Paolo: stiamo parlando dell’errore 500? πŸ™‚

      Risposte al commento di camu

      1. Paolo
        ha scritto:

        @camu: Nono, una presentazione del pacchetto di Tophost, nessun errore…E’ strano? πŸ™

        Risposte al commento di Paolo
        1. camu
          ha scritto:

          @Paolo: mi fai vedere in privato le stringhe del tuo htaccess? πŸ™‚

          Risposte al commento di camu
        2. Paolo
          ha scritto:

          @camu: C’è posta per te πŸ˜€ Grazie per il gentile aiuto πŸ˜‰

  8. Alx
    ha scritto:

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

    Risposte al commento di Alx

    1. camu
      ha scritto:

      @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 scritto:

    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

Rispondi a camu

Torna in cima alla pagina