Since nginx is faster than apache, why hasn't nginx replaced apache?

Many cloud host integrated environments or various public clouds now provide lighttpd or nginx servers by default. Why haven’t these higher-performance server software replaced apache?

Reply content:

Many cloud host integrated environments or various public clouds now provide lighttpd or nginx servers by default. Why haven’t these higher-performance server software replaced apache?

Nginx is definitely lighter and more efficient than Apache, and both are very stable.

Netcraft statistics, in February 2016, among the top one million busiest sites, Apache accounted for about 46%, Nginx about 25%, and IIS less than 12%. It is worth noting that among the top one million busiest sites, Nginx’s share is about 25% and maintains a growing trend, while Apache and IIS are both showing a downward trend. In other words, it is a trend for high-concurrency websites to turn to Nginx. For example, Tengine used by domestic Alibaba is a branch based on the secondary development of Nginx.

For most virtual host users, high concurrency is out of the question, because bandwidth is the bottleneck, and there is no need to talk about concurrency with 2M bandwidth, right? Moreover, Apache supports .htaccess configuration without reloading the configuration, which is easy to use. The configuration is better than that of Nginx. That is to say, the Apache+PHP architecture is simpler than Nginx. If you are not pursuing any concurrency scenarios, why should you change the architecture? As long as it is enough and easy to use.

Nginx returns 502 Bad Gateway error not because of Nginx problem, but because of backend problem.
For example, when the backend PHP-FPM process crashes when processing a request, then Nginx will return 502 error.
Of course you can use fastcgi_next_upstream Configure Nginx to transfer the request to another upstream for processing.
fastcgi_next_upstream error timeout invalid_header http_500 http_502 http_504;
Nginx+PHP-FPM achieves dynamic and static separation, load balancing, and failover. It does have advantages over Apache in high concurrency scenarios. .
The Apache process with built-in PHP module cannot process static resources when processing PHP, but Nginx does not need to worry about this problem, because processing PHP is a matter of PHP-FPM, which is the separation of dynamic and static. And Nginx supports upstream configuration of PHP-FPM Clusters implement load balancing, which is something Apache is not good at.

PHP-FPM combined with Nginx can also separate I/O-intensive operations and reduce the impact of blocking on the entire PHP application.
User downloads and curl requests are typical I/O-intensive operations, because time-consuming operations mainly occur on the network I /O and disk I/O.
Download operations that require PHP authentication can be delegated to Nginx's AIO thread pool:
header("X-Accel-Redirect: $filepath");
As for the curl operation, for example, you can create a The PHP-FPM process pool (pool) named io that listens to port 9001 is specifically responsible for processing curl operations (distributed through Nginx) to prevent curl operations from being blocked by the www process pool that listens to port 9000.
At this time, the io process pool is opened It doesn’t matter if you click on the progress:

<code>nginx.conf: 访问io.php的请求都交给监听9001的PHP-FPM进程池处理
location = /io.php {
    include fastcgi_params;
    fastcgi_pass 127.0.0.1:9001;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
php-fpm: 正常脚本由静态www池处理,阻塞脚本由动态io池处理
[www]
;名为www的进程池监听9000端口,常驻进程数量为固定4个
listen = 127.0.0.1:9000
pm = static
pm.max_children = 4
[io]
;名为io的进程池监听9001端口,进程数常驻4个,最大8个
listen = 127.0.0.1:9001
pm = dynamic
pm.max_children = 8
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 4</code>

The I/O intensive process pool [io] uses dynamic prefork processes, for example, 8 when busy and 4 when idle.

Use the isolation of the pool provided by PHP-FPM to separate computing intensive and I/O Intensive operations can reduce the impact of blocking on the entire PHP application.

The counterpart to fast is stability.

For some websites that do not have very high performance requirements such as concurrency, using apache is a good choice.

Because the two things have different focuses, Apache itself has many built-in things and can support almost all web-type applications without the help of other things. Nginx is different. It has advantages in static file processing and high concurrency.

Apache focuses on completeness and stability, while Nginx focuses on lightweight and high efficiency. In many cases, Apache and Nginx are used together. Nginx is configured in front of Apache and is used to block requests for static files (requests for resources on the website account for a large part today) Partially), the content that Nginx cannot handle is forwarded to Apache for processing.

nginx is indeed better, but not all websites have to use something that pursues the ultimate, just muddle along. In the final analysis, people are lazy and unwilling to accept new things, and are afraid of risks and responsibilities.

LAMP’s pot can be used once it is installed, and the training teacher has taught you that one has to learn. When many people encounter problems, they would rather spend 10 times more working time to adapt to something they know how to use, and then spend more time later. I don’t want to spend 100 times the time to fill this big hole. I don’t want to spend a day learning something new.

Everything has advantages and disadvantages, so it will be difficult to completely replace it. The best thing is to use it in combination. Besides, many people used apache in the past. Many people are too lazy to make new things. People are resistant to new things at the beginning, as if you have not come to the Imperial City. When I was there, I recalled that the subway was so crowded and fast-paced. When you actually come, you will find that it is not that scary

Mainly because Nginx needs to be restarted after changing the configuration file to take effect. Unlike Apache, which can directly parse the .htaccess file, the host cannot restart Nginx just because the user has modified their own configuration file. This will affect the use of other users. .