Indice dei contenuti dell'articolo:
Ci sono situazioni come quelle dei siti ad alto traffico (siti con milioni di visitatori al giorno per intenderci) in cui a livello tecnologico e sistemistico si ricerca la ricetta ideale per poter offrire il massimo delle performance al minor costo computazionale possibile. Se guardiamo tutti i progetti di siti ad alto traffico basati su tecnologie open source (e dunque non .net di Microsoft ad esempio) troveremo che avremo come unica costante e denominatore un webserver di cui abbiamo parlato in questo articolo : NGINX.
Tra gli innumerevoli PRO NGINX ha anche un apparente “contro”, ovvero quello di non disporre del supporto di htaccess come ad esempio il più ben famoso Apache Web Server.
Cos’è htaccess ?
Il file .htaccess (Hypertext Access) è un file di configurazione attraverso cui è possibile modificare le impostazioni di una directory specifica (ovvero di uan cartella specifica). Per directory specifica, in questo contesto, si intende che tutte le impostazioni scelte per quella directory specifica si applicano anche a tutte le subdirectory (o sotto cartelle). Un file .htaccess può essere usato solo con server NCSA compatibili, come per esempio server Apache che supportano moduli come mod_rewrite. Questo tipo di file è parte integrante delle configurazioni del server e ogni sua modifica si riflette automaticamente sul sito.
NGINX non supporta htaccess
Qualcuno crede erroneamente che il motivo sia in una presa di posizione dello sviluppatore legato alla “pigrizia” di implementare una funzionalità che risulta di sicuro comoda su Apache.
Ma come ben abbiamo imparato dal mondo della Formula 1 e della velocità in generale, se vogliamo correre veloci ed essere competitivi dobbiamo fare delle rinunce al fine di alleggerire il peso del veicolo o del webserver.
In questo caso appunto la mancanza del supporto htaccess non è un difetto, ma bensì una feature. Ovvero più specificamente uno di quei rari casi in cui non avere qualcosa non è un difetto ma un pregio.
Se vuoi a tutti i costi usare .htaccess probabilmente stai sbagliando e non dovresti farlo.
Perché?
Questa è un’ottima domanda Per cominciare, per far funzionare .htaccess Apache deve controllare OGNI directory nel percorso richiesto per l’esistenza di un file .htaccess e, se esiste, ne legge OGNI uno e lo analizza. Questo accade per OGNI richiesta. Ricorda infatti che nel momento in cui cambi quel singolo file, la modifica va subito in porto senza dover riavviare il web server, proprio perché Apache lo legge ogni volta.
Numeri
http://example.com/site/files/images/layout/header.png
Diciamo che non stiamo facendo alcun alias e il file system è il percorso. Questo caso è uno scenario comune con la maggior parte dei siti là fuori.
C’è la directory /, quindi site /, files /, images / e layout /. Ciò equivale a 5 directory che potrebbero avere un file .htaccess. Supponiamo che tu abbia aggiunto un .htaccess in /, files / e images /. Sono tre file .htaccess. È abbastanza tipico.
Ora i numeri, ovvero 6 stat del file system e 4 letture del file system. Di cui uno per il file richiesto. Questo succede per ogni lettura. Ignoreremo il tempo di analisi perché sia
| Richieste / Ora | Stat NGINX | Letture NGINX FS | Stat di Apache | Letture Apache FS | Commento |
|---|---|---|---|---|---|
| 1 | 1 | 1 | 6 | 4 | Richiesta singola [praticamente senza carico] |
| 10 | 10 | 10 | 60 | 40 | Dieci richieste [praticamente senza carico] |
| 3.600 | 3.600 | 3.600 | 21.600 | 14.400 | 1 req / sec [carico molto basso] |
| 144.000 | 144.000 | 144.000 | 864.000 | 576.000 | 40 req / sec [Traffico moderato – niente di molto grande] |
| 324.000 | 324.000 | 324.000 | 1,944,00 | 1.296.000 | 90 req / sec [Sito a traffico maggiore – non massiccio] |
| 576.000 | 576.000 | 576.000 | 3.456.000 | 2.304.000 | 160 req / sec [Traffico piuttosto elevato, anche se non ancora massiccio] |
Ancora più numeri e lentezza
L’impostazione predefinita per Apache è l’uso di AllowOverride All. Diamo un’occhiata a questo per un sito Web Drupal. Un’immagine per il tema. Se il tuo sito web DocRoot è su, /var/www/drupal6/abbiamo appena aggiunto altre statistiche sul file system. Questo aggiunge 3 statistiche per richiesta. Questa è un’installazione Apache / Drupal incredibilmente comune. È il risultato finale di innumerevoli guide là fuori.
/var/www/drupal6/sites/example.com/themes/yourtheme/images/layout/header.png
Due file .htaccess saranno in questo percorso a meno che tu non li crei. Presumo che tu ne abbia aggiunto uno in /var/www/ perché questo è comune.
| Richieste / Ora | Stat NGINX | Letture NGINX FS | Stat Apache FD | Letture Apache FS | Commento |
|---|---|---|---|---|---|
| 144.000 | 144.000 | 144.000 | 1.296.000 | 576.000 | 40 req / sec |
| 324.000 | 324.000 | 324.000 | 2.916.000 | 1.296.000 | 90 req / sec |
| 576.000 | 576.000 | 576.000 | 51.840.000 | 2.304.000 | 160 req / sec |
Interpretazione dei dati
Per essere molto diretti senza troppi giri di parole e diplomazia, Apache nel caso peggiore fa 100 volte accessi I/O rispetto a NGINX, nella migliore delle ipotesi dell’esempio sopra ne fa 10 volte tante.
E abbiamo voluto proporre un caso comune non troppo ottimale ne pessimo, ma pensiamo a quelle directory annidate che vanno in profondità per 20 o 30 nodi. Avete idea di quello che diventa ? Apache fa 1000 operazioni in più rispetto a quella singola di NGINX. Davvero troppo anche per il fanboy più sfegatato di Apache e del supporto htaccess.
Riscontro pratico sulle prestazioni
Un riscontro reale sulle prestazioni implica che ci sarà un I/O sul disco davvero importante nel momento in cui avremmo un sito molto trafficato e relative moltissime request per secondo. Immaginate che avete comprato l’ultimo modello di disco a stato solido SSD nVME da 1Gbit/s per garantirvi performance e throughtput I/O sul vostro server WordPress ad alte performance e poi ci andate a mettere Apache. In alcuni casi arriverete a degradare così tanto le prestazioni e l’I/O anche a livello kernel che otterrete le stesse prestazioni di un disco meccanico HDD SATA.
Apache dunque va bene per siti classici ma non per siti ad alte performance.
Vieni da Apache vuoi migrare a NGINX ma hai bisogno necessariamente di htaccess ?
Uno dei motivi per cui non si è restii a convertirsi a NGINX è quello dell’abitudine con cui siete cresciuti professionalmente ad utilizzare Apache fornito di default su pannelli come cPAnel o Plesk. Se si nasce, cresce con una tecnologia è normale e pacifico morire anche con la stessa identica tecnologia. Ci vuole un po’ di curiosità ed autocritica per mettere in dubbio alcune false convinzioni e provare a fare meglio utilizzando una soluzione tecnologica che comunque è montata sulla maggior parte dei siti ad alto traffico.
Il problema principale è quello di continuare ad usare .htaccess in un sistema che di fatto non supporta .htaccess. Concetto che se letto in maniera veloce fa venir voglia di chiudere la pagina e continuare con il buon vecchio Apache, ma aspetta forse non ci siamo capiti c’è dell’altro che dovresti sapere e che sicuramente ti piacerà.
Non leggere htaccess non significa non poter usare regole di rewrite
Abbiamo scritto fino ad ora che NGINX non legge i file htaccess ma non che non possa usufruire delle funzionalità di rewrite. htaccess è un formato proprietario usato essenzialmente solo da Apache e quindi dire che NGINX non legge htaccess è un po’ come dire che NGINX non legge un formato proprietario di Apache ma non che possa avere a modo suo, secondo le proprie regole le stesse funzionalità anche migliori di htaccess.
L’unico problema è cercare di capire come si possa convertire un progetto da htaccess APACHE al rewrite di NGINX.
Regole di Rewrite su NGINX
NGINX come abbiamo detto supporta le regole di rewrite a modo suo. Lo fa secondo una sua propria sintassi del tutto differente a quella di htaccess, lo fa secondo una sua filosofia che è quella di fare il match delle regole all’avvio del webserver e solo in quel momento. Pertanto le regole di rewrite a differenza di Apache verranno scritte nella configurazione del virtual host e saranno valide per tutta la durata di esecuzione del webserver. Non esiste la possibilità di creare un file .htaccess (o un eventuale equivalente NGINX) e di farlo digerire al webserver senza restartare il servizio.
Su NGINX se vuoi inserire una nuova regola di rewrite come ad esempio un banale redirect 301 da una vecchia pagina cancellata ad una nuova, devi editare il file di configurazione del vhost in questione come ad esempio nomesito.conf aggiungere la regola di rewrite e poi effettuare il reload e il restart del webserver secondo la sintassi service nginx reload o service nginx restart per far ricaricare la nuova regola inserita e farla funzionare correttamente.
Problemi commerciali e organizzativi
Uno dei problemi importanti della poca diffusione di NGINX oltre che per la mancanza del supporto .htaccess è data dal fatto che per scrivere nuove regole di rewrite nel vhost si deve necessariamente metter mano al vhost e restartare il webserver. Operazioni entrambe che richiedono i privilegi di superutente ovvero la root. In un ambiente di shared hosting in cui l’utente medio non è un sistemista mettere mano a questi task sarebbe stato del tutto impossibile, minando dunque la vendita di servizi di hosting low cost o per l’utente medio.
Solo ultimamente alcuni pannelli di controllo come Plesk e cPanel hanno implementato tramite la solita interfaccia punta e clicca la possibilità di scegliere quale webserver utilizzare tra NGINX e Apache (e anche un mix delle due soluzioni tramite reverse proxy) ma nonostante ciò molti webmaster, sviluppatori e SEO continuano incalliti ad utilizzare il solito vecchio Apache.
Convertire htaccess a NGINX
Potremmo fare i fenomeni e dire che in fondo convertire un .htaccess a NGINX non è complessissimo in quanto la sintassi stessa è piuttosto semplice (a nostro avviso anche più facile di quella nativa htaccess), ma poi cosa vi racconteremo nel momento in cui devi convertire quelle 500 linee di rewrite da htaccess a NGINX ? 3 o 4 giorni per convertire tutte le regole ? No grazie.
Esistono soluzioni più rapide e immediate messe a disposizione da aziende che hanno deciso di rendere disponibile pubblicamente dei convertitori online che permettono di convertire le regole di rewrite da htaccess a NGINX.
Purtroppo non essendoci nulla di ufficiale ed efficace la maggior parte tendono a produrre regole che o non funzionano o funzionano ma si approcciano con una sintassi errata.
Tuttavia il migliore in circolazione che permette nel 99% dei casi di convertire regole medio complesse (come ad esempio dei rewrite 301 e simili) è quello che trovate a questo link
E’ di fatto come dice il nome stesso un htaccess converter che permette appunto di convertire htaccess a regole NGINX. Ecco ad esempio un utilizzo reale di questa sera che ci è servito per portare il sito di un nuovo cliente da Apache a NGINX per motivi di performance.
Andando ad incollare le regole .htaccess nella sezione htaccess e premendo il bottone “converti” ci verrà restituita la rispettiva sintassi NGINX che andremo a copiare ed incollare nella configurazione del virtual host NGINX e poi restartare il webserver per testare la correttezza.
Conclusioni
Se hai siti del salumiere o della pizzeria sotto casa con poche visite al mese vai pure con Apache e .htaccess, se gestisci siti ad alto traffico e ad alte performance usa NGINX come fanno tutti i siti al altissimo traffico.
Noi usiamo NGINX e lasciamo Apache ai dilettanti.
