Since Nginx is faster than Apache, why does Nginx not replace Apache?

Many cloud hosts now have an integrated environment or a variety of public clouds that are provided by default for LIGHTTPD or Nginx servers, and why are these higher performance server software not replacing Apache?

Reply content:

Many cloud hosts now have an integrated environment or a variety of public clouds that are provided by default for LIGHTTPD or Nginx servers, and why are these higher performance server software not replacing Apache?

Nginx is more lightweight and efficient than Apache, and both are stable.

Netcraft statistics, February 2016, in the top 1 million busiest sites, Apache about 46%,nginx about 25%,iis less than 12%. It is important to note that in the first million busy sites, Nginx share of about 25% and maintain the trend of growth, Both Apache and IIS are trending down. That is, the high concurrency of the site to Nginx is a trend, such as the domestic Ali used Tengine is based on Nginx two development branch.

And for most of the virtual host users, is not high concurrency, because the bandwidth is the bottleneck, 2M bandwidth also talk about what concurrency, is it. and Apache supports no overload configuration. htaccess configuration, in the ease of use than nginx configuration better. That's apache+. PHP architecture is more simple than nginx, in the pursuit of what is not concurrent scenarios, why change a set of architecture? Enough can be used on the line.

Nginx returned 502 Bad Gateway error is not due to nginx problem, but because of back-end problems.
For example, the backend PHP-FPM process crashes when processing a request, then Nginx returns a 502 error.
Of course you can use Fastcgi_next_upstream configuration to let Nginx transfer the request to another upstream processing.
fastcgi_next_upstream error timeout invalid_header http_500 http_502 http_504;
NGINX+PHP-FPM realizes dynamic and static separation, load balancing, and failover, and in high concurrency scenarios, it is indeed advantageous than Apache.
The Apache process with built-in PHP modules cannot handle static resources while working with PHP, and Nginx does not need to worry about this because it is php-fpm to handle PHP, which is the separation of motion and motion. and Nginx supports upstream configuration PHP-FPM cluster for load balancing , and this is what Apache is not good at.

PHP-FPM with Nginx can also separate I/O intensive operations to reduce the impact of blocking on the entire PHP application.
User downloads and Curl requests are typical I/O intensive operations, because time-consuming occurs primarily in network I/O and disk I/O.
Download operations that require PHP authentication can be delegated to the Nginx AIO thread pool:
header("X-Accel-Redirect: $filepath");
As for curl operations, such as the ability to create a PHP-FPM process pool called Io that listens on port 9001,
Specifically responsible for handling curl operations (via Nginx distribution), to avoid blocking the curl operation to the listening 9000 port of the WWW process pool.
At this point the IO process pool is more open process also does not matter:

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:9000pm = staticpm.max_children = 4[io];名为io的进程池监听9001端口,进程数常驻4个,最大8个listen = 127.0.0.1:9001pm = dynamicpm.max_children = 8pm.start_servers = 4pm.min_spare_servers = 4pm.max_spare_servers = 4

where I/O intensive this process pool [IO] uses a dynamic prefork process, such as here is 8 busy, 4 idle.
The isolation of the pools provided by the PHP-FPM, separating compute dense and I/O intensive operations, can reduce the impact of blocking on the entire PHP application.

Corresponding to the fast phase, is stable.
Some are not very high performance requirements for concurrency, the use of Apache is a good choice.

Because the focus of two things is different, Apache has built up a lot of things to support almost all Web-type applications without needing anything else. But Nginx is different, it has the superiority in the static file processing, the high concurrency aspect.
Apache focuses on the integrity of the stability, and nginx focus on the lightweight and efficient, many times the Apache and Nginx is used in conjunction with Nginx configuration in front of Apache, with it to block out the static file requests (the site today's resource requests accounted for most of the), Nginx can not handle the content of the dish is forwarded to Apache to deal with.

Nginx is really better, but not all the site to use how to pursue the ultimate thing, muddle along on the line. In the final analysis, people are lazy unwilling to accept new things, afraid of risk, afraid of responsibility.

Lamp pot, a loaded on can use, and the training of the teacher taught, a to learn, many people encounter problems are rather more than 10 times times the work time to fit a self will, then spend 100 times times the time to fill this big pit is not willing to spend a day learning a new thing.

Everything has advantages and disadvantages so a complete replacement will be very difficult best is combined with a lot of the previous use of Apache a lot of people do not bother to make new things people are just beginning to the new things have a resistance to the mind as if you did not come to the Royal Park when you think of the subway to die beat'm going aunt you really come will find also not so scary

The main reason is that Nginx changes the configuration file after the need to restart to take effect, unlike Apache can directly parse. htaccess files, and the host is not possible because users modify their own configuration file after the restart Nginx, which will affect the use of other users.

