Table of contents of the article:
There are situations such as those of high traffic sites (sites with millions of visitors per day to be clear) in which the ideal recipe is sought at a technological and systemic level in order to offer maximum performance at the lowest possible computational cost. If we look at all the projects of high traffic sites based on open source technologies (and therefore not Microsoft's .net for example) we will find that we will have as the only constant and denominator a webserver we talked about in this article: Nginx.
Among the countless PRO NGINX also has an apparent "against", namely that of not have htaccess support such as the more well-known Apache Web Server.
What is htaccess?
The .htaccess file (Hypertext Access) is a configuration file through which you can change the settings of a specific directory (that is, of a specific folder). By specific directory, in this context, we mean that all the settings chosen for that specific directory also apply to all subdirectories (or subfolders). An .htaccess file can only be used with compatible NCSA servers, such as Apache servers that support modules like mod_rewrite. This type of file is an integral part of the server configurations and any changes to it are automatically reflected on the site.
NGINX does not support htaccess
Someone mistakenly believes that the reason is in a position taken by the developer related to the "laziness" of implementing a feature that is certainly convenient on Apache.
But as we have learned from the world of Formula 1 and speed in general, if we want to run fast and be competitive we must make some sacrifices in order to lighten the weight of the vehicle or the webserver.
In this case precisely the lack of htaccess support is not a defect, but rather a feature. Or more specifically one of those rare cases in which not having something is not a defect but a virtue.
If you want to use .htaccess at all costs, you are probably wrong and you shouldn't.
Why?
This is a very good question. To begin with, to get .htaccess to work Apache must check EVERY directory in the path required for an .htaccess file to exist and, if it exists, it reads EVERY one and analyzes it. This happens for EVERY request. In fact, remember that when you change that single file, the change goes immediately without having to restart the web server, precisely because Apache reads it every time.
Numbers
http://example.com/site/files/images/layout/header.png
Let's say we are not making any aliases and the file system is the path. This case is a common scenario with most of the sites out there.
There is the / directory, so site /, files /, images / and layout /. This is equivalent to 5 directories that might have an .htaccess file. Let's say you have added an .htaccess in /, files / and images /. There are three .htaccess files. It is quite typical.
Now the numbers, which is 6 file system stat and 4 file system read. Including one for the requested file. This happens for every reading. We will ignore the analysis time for it to be
| Requests / Hour | NGINX stats | NGINX FS readings | Apache stat | Apache FS readings | Comment |
|---|---|---|---|---|---|
| 1 | 1 | 1 | 6 | 4 | Single request [practically no load] |
| 10 | 10 | 10 | 60 | 40 | Ten requests [practically no load] |
| 3.600 | 3.600 | 3.600 | 21.600 | 14.400 | 1 req / sec [very low load] |
| 144.000 | 144.000 | 144.000 | 864.000 | 576.000 | 40 req / sec [Moderate traffic - nothing very big] |
| 324.000 | 324.000 | 324.000 | 1,944,00 | 1.296.000 | 90 req / sec [Higher traffic site - not massive] |
| 576.000 | 576.000 | 576.000 | 3.456.000 | 2.304.000 | 160 req / sec [Rather high traffic, although not yet massive] |
Even more numbers and slowness
The default for Apache is to use AllowOverride All. Let's take a look at this for a Drupal website. An image for the theme. If your DocRoot website is on, /var/www/drupal6/we just added more file system statistics. This adds 3 stats per request. This is an incredibly common Apache / Drupal installation. It is the end result of countless guides out there.
/var/www/drupal6/sites/example.com/themes/yourtheme/images/layout/header.png
Two .htaccess files will be in this path unless you create them. I assume you have added one in / var / www / because this is common.
| Requests / Hour | NGINX stats | NGINX FS readings | Stats Apache FD | Apache FS readings | Comment |
|---|---|---|---|---|---|
| 144.000 | 144.000 | 144.000 | 1.296.000 | 576.000 | 40 reqs/sec |
| 324.000 | 324.000 | 324.000 | 2.916.000 | 1.296.000 | 90 reqs/sec |
| 576.000 | 576.000 | 576.000 | 51.840.000 | 2.304.000 | 160 reqs/sec |
Interpretation of the data
To be very straightforward without too many words and diplomacy, Apache at worst does 100 times I / O accesses compared to NGINX, at best the example above does 10 times as many.
And we wanted to propose a common case that is not too optimal or bad, but let's think of those nested directories that go deep for 20 or 30 nodes. Do you have any idea what it becomes? Apache does 1000 more operations than NGINX single one. Much too much for even the most hardcore Apache and htaccess support fanboy.
Practical performance feedback
Real performance feedback implies that there will be really important disk I / O when we have a very busy site and a lot of requests per second. Imagine you bought the latest 1Gbit / s nVME SSD solid state drive to guarantee performance and I / O throughtput on your high-performance WordPress server and then go and put Apache there. In some cases you will degrade performance and I / O so much even at the kernel level that you will get the same performance as a mechanical SATA HDD.
Apache is therefore good for classic sites but not for high performance sites.
Are you from Apache do you want to migrate to NGINX but do you necessarily need htaccess?
One of the reasons why you are not reluctant to convert to NGINX is the habit with which you have grown professionally to use Apache provided by default on panels like cPAnel or Plesk. If you are born, grow up with a technology, it is normal and peaceful to die even with the exact same technology. It takes a bit of curiosity and self-criticism to question some false beliefs and try to do better by using a technological solution that is still mounted on most high-traffic sites.
The main problem is to keep using .htaccess on a system that doesn't actually support .htaccess. Concept that if read quickly makes you want to close the page and continue with the good old Apache, but wait maybe we didn't understand there is more you should know and that you will surely like.
Not reading htaccess doesn't mean you can't use rewrite rules
We have written so far that NGINX does not read htaccess files but not that he can't take advantage of the rewrite features. htaccess is a proprietary format used essentially only by Apache and therefore to say that NGINX does not read htaccess is a bit like saying that NGINX does not read a proprietary format of Apache but not that it can have the same functionality in its own way, according to its own rules. better than htaccess.
The only problem is trying to understand how you can convert a project from APACHE htaccess to NGINX rewrite.
Rewrite Rules on NGINX
NGINX as we said supports the rewrite rules in its own way. It does so according to its own syntax completely different from that of htaccess, it does so according to its philosophy which is to match the rules when the webserver starts and only at that moment. Therefore, the rewrite rules unlike Apache will be written in the virtual host configuration and will be valid for the entire duration of the webserver. There is no possibility to create an .htaccess file (or any NGINX equivalent) and have it digested by the webserver without restarting the service.
On NGINX if you want to insert a new rewrite rule such as a trivial 301 redirect from an old deleted page to a new one, you have to edit the configuration file of the vhost in question such as sitename.conf add the rewrite rule and then reload and restart the webserver according to the syntax service nginx reload or service nginx restart to reload the new rule inserted and make it work correctly.
Commercial and organizational problems
One of the important problems of NGINX's lack of diffusion as well as the lack of .htaccess support is the fact that to write new rewrite rules in the vhost you must necessarily go to the vhost and restart the webserver. Both operations require superuser privileges or root. In a shared hosting environment where the average user is not a system engineer, putting his hand to these tasks would have been completely impossible, thus undermining the sale of low cost hosting services or for the average user.
Only lately some control panels like Plesk and cPanel have implemented through the usual point and click interface the possibility to choose which webserver to use between NGINX and Apache (and also a mix of the two solutions via reverse proxy) but despite this many webmasters, developers and SEOs continue hard to use the same old Apache.
Convert htaccess to NGINX
We could do the phenomena and say that basically converting an .htaccess to NGINX is not very complex as the syntax itself is quite simple (in our opinion even easier than the native htaccess one), but then what we will tell you when you need to convert those 500 rewrite lines from htaccess to NGINX? 3 or 4 days to convert all the rules? No thanks.
There are faster and more immediate solutions made available by companies that have decided to make publicly available online converters that allow you to convert the rewrite rules from htaccess to NGINX.
Unfortunately, since there is nothing official and effective, most tend to produce rules that either don't work or work but approach with wrong syntax.
However, the best in circulation that allows in 99% of cases to convert medium-complex rules (such as rewrite 301 and the like) is the one you find at this link
It is in fact as the name implies a htaccess converter which allows you to convert htaccess to NGINX rules. Here is for example a real use of tonight which served us to bring a new customer site from Apache to NGINX for performance reasons.
Going to paste the .htaccess rules in the htaccess section and pressing the "convert" button we will return the respective NGINX syntax that we will copy and paste in the NGINX virtual host configuration and then restart the webserver to test the correctness.
Conclusions
If you have sites of the butcher or pizzeria under your house with a few visits a month go well with Apache and .htaccess, if you manage sites with high traffic and high performance use NGINX as do all sites with very high traffic.
We use NGINX and leave Apache to amateurs.
