Table of contents of the article:
There are situations, such as those of high-traffic websites (sites with millions of visitors per day, for example), where the technological and system requirements are met to find the ideal recipe for maximum performance at the lowest possible computational cost. If we look at all the high-traffic website projects based on open source technologies (and therefore not Microsoft's .net, for example), we'll find that the only constant and common denominator is the web server we discussed in this article: NGINX.
Among the countless PROs, NGINX also has an apparent “con”, that is, it does not have htaccess support like the more famous 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, the lack of htaccess support isn't a flaw, but rather a feature . More specifically, it's one of those rare cases where not having something isn't a flaw, but rather a benefit.
If you want to use .htaccess at all costs, you are probably wrong and you shouldn't.
Why?
This is a great question. To start, for .htaccess to work, Apache must check EVERY directory in the requested path for the existence of a .htaccess file , and if it exists, it reads and parses EVERY one. This happens for EVERY request . Remember, when you change that single file, the change goes live immediately without having to restart the web server, precisely because Apache reads it every time.
Contacts
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 parsing time because both NGINX and Apache have to do this and we will consider the time difference for this to be negligible.
| 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's neither optimal nor terrible, but think about those nested directories that go 20 or 30 nodes deep. Do you have any idea what that becomes? Apache does 1000 more operations than NGINX's single one . That's way too much even for the most die-hard Apache and htaccess support fanboy.
Practical performance feedback
A real-world performance measurement implies that disk I/O will be significantly increased if you have a high-traffic site with a large number of requests per second. Imagine you bought the latest 1Gbps nVME SSD to ensure performance and I/O throughput on your high-performance WordPress server, and then you install Apache on it. In some cases, you'll degrade performance and I/O so much, even at the kernel level, that you'll get the same performance as a 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've written so far that NGINX doesn't read htaccess files, but not that it can't take advantage of the rewrite features . htaccess is a proprietary format used essentially only by Apache, so saying that NGINX doesn't read htaccess is a bit like saying that NGINX doesn't read a proprietary Apache format, but not that it can have the same, or even better, features than htaccess in its own way, according to its own rules.
The only problem is trying to understand how you can convert a project from APACHE htaccess to NGINX rewrite.
Rewrite Rules on NGINX
As we've said, NGINX supports rewrite rules in its own way. It does so according to its own syntax, completely different from that of .htaccess, and it follows its own philosophy, which is to match the rules at the web server's startup and only then. Therefore, unlike Apache, rewrite rules are written to the virtual host's configuration and will be valid for the entire duration of the web server's execution. There's no way to create a .htaccess file (or any NGINX equivalent) and have the web server digest it without restarting the service.
On NGINX, if you want to insert a new rewrite rule, such as a simple 301 redirect from an old deleted page to a new one, you must edit the configuration file of the vhost in question, such as sitename.conf, add the rewrite rule, and then reload and restart the web server using the service nginx reload or service nginx restart syntax to reload the new rule and make it work correctly.
Commercial and organizational problems
One of the major problems with NGINX's limited use, besides the lack of .htaccess support, is that writing new rewrite rules in the vhost requires modifying the vhost and restarting the web server. Both operations require superuser, or root, privileges. In a shared hosting environment where the average user isn't a system administrator, performing these tasks would have been completely impossible, thus undermining the sale of low-cost or average-user hosting services.
Only recently have some control panels like Plesk and cPanel implemented the ability to choose which web server to use between NGINX and Apache (and even a mix of the two solutions via reverse proxy) via the usual point-and-click interface, but despite this, many webmasters, developers and SEOs continue to stubbornly 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 one out there that allows you to convert medium-complex rules (such as 301 rewrites and similar) in 99% of cases is the one you can find at this link
As the name suggests, it's an htaccess converter that allows you to convert htaccess files to NGINX rules. Here's an example of a real-world use case we used this evening to port a new client's 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.
