Since nginx is faster than apache, why does nginx not replace apache?

Currently, the integrated environment of many Cloud hosts or various public clouds also provide lighttpd or nginx servers by default. Why didn't these server software with higher performance replace apache? Currently, the integrated environment of many Cloud hosts or various public clouds also provide lighttpd or nginx servers by default. Why didn't these server software with higher performance replace apache?

Reply content:

Currently, the integrated environment of many Cloud hosts or various public clouds also provide lighttpd or nginx servers by default. Why didn't these server software with higher performance replace apache?

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

According to netcraft statistics, in February 2016, Apache was about 1 million, Nginx was about 46%, and IIS was less than 25% of the top 12% busiest sites. it is worth noting that, among the first millions of busy sites, Nginx shares are about 25% and keep increasing, while Apache and IIS are both declining. that is to say, it is a trend for high-concurrency websites to switch to Nginx. for example, the Tengine used by Alibaba in China is a branch developed based on Nginx.

For most VM users, there is no high concurrency at all, because bandwidth is the bottleneck. what concurrency should I talk about with 2 Mbps of bandwidth. in addition, Apache does not need to overload the configuration. htaccess configuration is easier to use than Nginx configuration. that is to say, the Apache + PHP architecture is simpler than Nginx. why should we change the architecture without pursuing any concurrency? You can use it easily.

Nginx returns the 502 Bad Gateway error not because of Nginx problems, but because of backend problems.
For example, the backend PHP-FPM crashes when processing a request, then Nginx will return 502 error.
Of course, you can use the fastcgi_next_upstream configuration to transfer requests 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, failover, high concurrency scenarios are indeed better than Apache.
The Apache process with built-in PHP module cannot process static resources when processing PHP, and Nginx does not need to worry about this problem, because processing PHP is a PHP-FPM, this is static and dynamic separation. and Nginx supports upstream configuration PHP-FPM cluster load balancing, this is Apache is not good.

PHP-FPM with Nginx can also separate I/O intensive operations to reduce the impact of blocking on the entire PHP application.
User Download and curl requests are typical I/O-intensive operations, because the time consumed mainly occurs in network I/O and disk I/O.
Download operations that require PHP authentication can be delegated to the AIO thread pool of Nginx:
header("X-Accel-Redirect: $filepath");
For curl operations, for example, you can create a PHP-FPM process pool (pool) that listens to Port 9001 named io ),
It is responsible for processing curl operations (distributed through Nginx) to prevent curl operations from being blocked to the www process pool listening to Port 9000.
At this time, the io process pool does not matter if multiple processes are enabled:

Nginx. conf: access io. php requests are all sent to the PHP-FPM process pool listening 9001 for location =/io. php {include fastcgi_params; fastcgi_pass 127.0.0.1: 9001; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name;} php-fpm: normal scripts are processed by the static www pool, the blocking script is processed by the dynamic io pool [www]; the process pool named www listens to Port 9000, and the number of resident processes is fixed to four listen = 127.0.0.1: 9000pm = staticpm. max_children = 4 [io]; the process pool named io listens to Port 9001, and the number of processes is resident at 4, with a maximum of 8 listen = 127.0.0.1: 9001pm = dynamicpm. max_children = 8. start_servers = 4. min _spare_servers = 4. max_spare_servers = 4

The I/O intensive process pool [io] uses dynamic prefork processes. for example, there are eight busy and four idle processes.
With the isolation of the pool provided by the PHP-FPM, separating computing intensive and I/O intensive operations can reduce the impact of blocking on the entire PHP application.

It is stable.
Some websites that do not have high requirements on concurrency and other performance, using apache is a good choice.

Because the focus of the two things is different, Apache itself has many built-in things that can be supported by almost all Web applications without the help of other things. Different from Nginx, Nginx has advantages in processing static files and high concurrency.
Apache focuses on integrity and stability, while Nginx focuses on lightweight and efficient. Apache and Nginx are often used in combination, and Nginx is configured before Apache, it is used to block requests to static files (the website's resource requests account for most of today), so content dishes that Nginx cannot handle are forwarded to Apache for processing.

Nginx is indeed better, but not all websites have to pursue the ultimate in their own ways. In the end, it is people's laziness who are unwilling to accept new things, fear risks, and take responsibility.

LAMP pot, one installed can be used, and the training teacher taught, one to learn, many people prefer to spend 10 times more time adapting to what they will do, and spend another 100 times more time filling out this big pitfall. they do not want to spend a day learning new things..

Everything has advantages and disadvantages, so it is very difficult to completely replace it. it is best to combine it with it. Besides, there are a lot of apache users who have used it before, too many people are too lazy to get new things. people have a resistance to new things at the beginning. it's as if you didn't come to the Imperial Palace, think about the subway, and it's so busy. when you really come, you will find that it's not that scary.

It is mainly because the Nginx configuration file needs to be restarted to take effect, unlike Apache which can be directly parsed. but it is impossible for the host provider to restart Nginx after the user modifies its configuration file, which affects the use of other users.