This article is from Mobingi official technical column, welcome to follow
Apache vs Nginx: Practical Considerations
Introduction to the
Apache and Nginx are two of the most popular open source Web servers in the world, together supporting more than 50% of the traffic on the Internet. Both support multiple load patterns and can be integrated with other software services to provide a full-stack Web solution.
Although Apache and Nginx have a lot in common, you shouldn’t assume that they are completely interchangeable. They all have their own strengths, and knowing them will help you re-evaluate your web server choices. This article is devoted to discussing the different performance of the two servers in different domains.
An overview of
Before we dive into the differences between Apache and Nginx, let’s briefly review the background and features of the two projects.
Apache
The Apache HTTP server was developed in 1995 by Robert McCool under the leadership of the Apache Software Foundation (founded in 1999). It is often referred to as “Apache” because it is the foundation’s original project and is by far the foundation’s most famous software.
Apache has been the most popular Web server software on the Internet since 1996. Because of its popularity, the Apache Foundation can benefit from providing sophisticated documentation and system integration support to other software projects.
Apache is often chosen as a Web server by system administrators because of its flexibility, performance, and wide support. It can be extended by dynamically loading modules and can execute multiple interpreted languages without connecting to other third-party software.
Nginx
In 2002, Igor Sysoev started writing an Nginx server to solve the C10K problem. The C10K problem is a challenge for web servers, requiring a Web server to handle 10,000 connection requests at a time. The latest version of Nginx, released in 2004, addresses this need using an out-of-date, event-based mechanism.
Nginx has become popular because it takes very few resources and is very easy to use with the underlying hardware extensions. Nginx excels at serving static content and is designed to forward requests that require dynamic content processing to other software to solve 10K problems.
Nginx is often chosen by server administrators for its low resource consumption and high load capacity, and its advocates have welcomed Nginx’s focus on the core features of Web servers and proxy servers.
Connection handling mode
One big gap between Apache and Nginx is the way they actually handle connections and requests. This results in very different performance of the two servers under different network traffic conditions.
Apache
Apcahe provides multiple multi-process working modes (Apache calls these MPMs, multi-processing Modules) to handle requests, basically allowing administrators to easily change the way the server handles connections. These patterns are as follows:
-
Mpm_prefork: This pattern creates a process to process each request. Each child process processes only one request at a time. If the number of requests is smaller than the number of processes, this mode runs very fast. However, when the number of requests to handle exceeds the number of processes, the performance degradation is severe, so this pattern is not a good choice for many application scenarios. Each process consumes a significant amount of memory, so this working mode is difficult to optimize. This may still be a good choice in cases where the internal component processing the request does not support the threaded working mode. PHP, for example, is not thread-safe, so this working mode is recommended as the only safe mode to run with mod_PHP.
-
Mpm_worker: This mode creates processes that can manage their own threads. Each thread can process one connection separately. Because the system can create many more threads than processes, this mode can handle many more connections than prefork mode. A new connection is processed immediately, without waiting for an idle process to process it.
-
Mpm_event: This mode is similar to worker mode, but optimizes the way keep-alive requests are handled. When using worker mode, a connection holds a thread until the connection dies, regardless of whether there are requests coming from the connection or not. In event mode, a dedicated thread processes and holds connections, and then forwards requests to other threads for processing. This allows the system to escape the quagmire of processing a large number of keep-alive requests, allowing the request processor to execute faster. This pattern has been marked as stable in Apache version 2.4.
As you can see, Apache provides a flexible structure for configuring different connection and request processing algorithms. These operating modes represent the evolution of server functionality and the increasing need for large concurrent processing as the Internet landscape changes.
Nginx
Nginx came to the scene after Apache and was born with the need to confront the big and ask questions. Taking advantage of this understanding, Ngeix thoroughly uses non-synchronous, non-blocking, and event-driven connection processing algorithms from the inside out.
Nginx generates worker processes, each of which can handle thousands of connections. The worker process continuously retrieves and processes events by implementing a fast loop algorithm. Separate the actual request processing from the connection so that each worker process is only associated with a connection when a new event occurs.
All connections processed by worker processes are placed in an event loop, in which events are processed asynchronously, making processing a non-blocking process. When the connection is closed, the connection is removed from the loop.
This connection allows Nginx to handle an incredibly large number of requests with limited computing resources. Because the server is single-threaded and does not generate a separate process for handling a new connection, memory and CPU consumption tend to remain relatively consistent, even in cases of large concurrency.
Static content vs. dynamic content
In practical terms, the most common comparison between Apache and Nginx is the way they handle static and dynamic content when a request comes in.
Apache
Apache uses a traditional file-based approach to handle requests for static content. Its performance depends mainly on which mode it is set to work (mentioned above).
Apache can also handle dynamic content by embedding a processing language into the running instance so that dynamic content can be handled inside the server without relying on external components. It starts the process of processing dynamic content by using dynamically loadable modules.
Apache’s ability to process dynamic content within the server means that configuring dynamic processing is also relatively simple. There is no need to interact with an additional piece of software and modules are easy to replace when content handling requirements change.
Nginx
Ngnix itself does not have any dynamic processing capability. If you want to execute PHP code or generate dynamic content for a request, Nginx must pass the request to an external processor and wait for the rendered content (usually an HTML document) before forwarding it to the client.
For server administrators, this means that you must configure the interaction between Nginx and external processors over a protocol (HTTP, FastCGI, SCGI, uWSGI, memcache) that Nginx understands. This can make things slightly more complicated, especially when trying to occupy the maximum number of connections allowed, since there is already an extra connection to forward requests to the processor.
However, this model also has some advantages. Because the dynamic interpreter is not embedded in Nginx’s worker process, its overhead is limited to handling dynamic content, whereas static content requests are handled directly and Nginx only connects to the program interpreter when needed. Apache can also work this way, but then it loses the benefit we talked about earlier.
Distributed configuration vs. centralized configuration
For server administrators, the most obvious difference between the two servers is whether folder level configuration is allowed.
Apache
Apache provides an option that allows you to set additional configurations for each directory. This function is based on monitoring and translating commands in a hidden file in the folder where the content resides. This file is known as.htacess.
The.htacess file exists in the requested content folder. When processing a request, Apache checks the path of each file, looks for the.htacess file, and executes the commands inside, which makes decentralized configuration of the server possible. This feature is often used to rewrite urls, control access and even cache policies.
Although the above example can be set in Apache’s main configuration file. However, Htacess has some important advantages. First, Apache interprets instructions every time a request comes in, so the configuration of.htacess takes effect immediately without the need to restart the server. Second, it allows unauthorized users to control certain aspects of their own Web content without modifying the Apache master configuration file.
This gives some Web software, such as content management systems (CMS), an easy way to fund themselves without having to access the master configuration file. This is also used to share hosting providers to give customers control over their own specific directories while maintaining control over the main configuration files.
Nginx
Nginx does not immediately interpret.htacess files, nor does it provide any technology to support directory-level configuration beyond the main configuration file. This may be less flexible than Apache, but it has its advantages.
One of the most well-known system advantages of directory level configuration over the.htacess mechanism is improved performance. For example, a typical Apache configuration might allow.htaccess to be configured in any directory, so that every time someone accesses a resource in any directory, the server checks that directory and all of its parent. If one or more. Htaccess files are found during this process, they must be read and interpreted for execution. Nginx does not allow directory rewriting, and Nginx only finds and reads one file per request (assuming the file can be found under the convention directory structure), so Nginx handles requests faster.
Another advantage is security. Decentralized directory-level configuration also places the responsibility for configuring web services securely on each user (the Web application administrator), who may not be up to the task. Ensuring that the server administrator controls the entire Web server prevents some of the security risks of transferring control to someone else.
If these ideas resonate with you, you should always consider whether you can close the interpret.htaccess file.
File VS interpretation execution based on URIs
How does the Web server interpret the execution of a request and find the system resource that matches the request? This is another difference between the two servers.
Apache
Apache provides the ability to convert requests to physical resources on the file system or to a more abstract URI. In general, previous Aapache uses or block configuration, while using block configuration for more abstract resources.
Because Apache was designed for web servers. By default a request is usually interpreted as a file resource request. It finds the real file relative to the Document root path after removing the domain name and port number from the request path. By default, the file structure is presented as a document tree.
When a request does not match a file resource, Apache provides a number of options for handling the situation. For example, an alias command can associate a request to another location. Using blocks allows you to work with URIs instead of file systems. You can also use regular expressions to make file-system-based resource look-up more flexible.
Although Apache has the ability to manipulate both the underlying file system and the web space, it relies heavily on the file system, including directory-level configuration using.htacces files, which can be seen as its design philosophy. Apache Docs warns users not to restrict access with urI-based configurations when requests can be mapped to the underlying file system.
Nginx
Nginx was created as a Web server and proxy server. Consider the architecture required for both roles, which works primarily based on URIs. Map requests to the file system only when needed. This can be seen as a way of structuring and interpreting the implementation of Nginx configurations. Nginx does not provide any configuration about the file system directory, instead parsing the URI itself.
For example, Nginx’s main configuration blocks are the Server and Location blocks. The Server configuration block is used to interpret the domain name portion of the request, and the Location configuration block is used to match the portion of the URI following the domain name and port number. From this point of view, the request is interpreted as a URI request, not a file mapped to the file system.
For static files, all requests are eventually mapped to a file on the file system. First, Nginx finds the Server configuration block and location configuration block used to process the request, then combines the Document root directory and URI, and makes any necessary adjustments based on the specified configuration.
This may seem simple, but parsing requests to URIs instead of file system paths allows Nginx to work with web, mail, and proxy servers simply by configuring them to correspond to different modes of request requests. Nginx does not examine the file system until it is ready to serve the requested content, which explains why it does not implement a configuration similar to.htaccess.
The module
Nginx and Apache both support server extension through modules, but they work in very different ways.
Apache
Apache’s module system allows you to dynamically load and unload modules while the server is running. The Apache core is always there, and modules can be turned on or off to add or remove additional functionality mounted to the main program section of the server. Apache does a lot with this one feature. Because the Apache platform is so mature, there are many modules for extending Apache. They can be used to change some of the core functionality of Apache, for example mod_PHP can embed the PHP processor in every running worker process.
Modules are not limited to dynamic content; they are also used for URL rewriting, authentication clients, hardware-based servers, logging, caching, compression, proxies, rate control, encoding, and more. Dynamic modules can easily extend core functionality without requiring much extra work.
Nginx
Nginx also implements a modular system, but it is implemented in a very different way than Apache. In Nginx, modules are not dynamically loaded; they must be compiled into Nginx core programs.
For many users, this may feel like Nginx is not flexible enough. This can be a problem especially for users who only install releases and are not familiar with managing and maintaining their own software through compilation. However, distributions tend to include the most widely used modules, and if you need a nonstandard module, you will have to compile your own Nginx server software.
Compiling Nginx modules is also very useful, they allow you to figure out which features you don’t want on the server and which features you need to use. Many users also think it is more secure because the unselected components are not mounted to the server. Either way, if your server is already configured, it’s probably a compromise.
The Nginx module has many features similar to the Apache module. For example, the Nginx module can provide proxy services, compression, rate control, logging, rewriting, geolocation, authentication, encoding, streaming and mail functions.
Support, compatibility, ecosystem, and documentation
The key to thinking about this is what your application does and what other applications it needs to work with.
Apache
Because Apache has been popular for so long, support for it is almost universal. There is a lot of official and third-party documentation that describes the core server and how to mount other software to the core server.
Nginx
Because of Nginx’s high performance, more and more users choose to use Nginx, and more and more software starts to support Nginx. However, Nginx has yet to catch up with Apache in a number of key areas.
In the past, it was difficult to find a comprehensive documentation of Nginx. Because much of the early development was done by Russians, the documentation was in Russian. As the project grew in popularity, there was a lot of documentation and a lot of administrator resources on the Nginx website as well as on third-party sites.
Out of respect for third-party software, technical support documentation became more readable, and Nginx package maintainers began to allow free conversion of configuration between Apache and Nginx in some cases. Even without technical support, configuring the Nginx server to work with optional software is often straightforward, as described in its project documentation.
Apache is used with Nginx
Now that we’ve looked at the strengths and weaknesses of Apache and Nginx, you’ve probably decided which server is best for your needs. However, many users find that they can get all the benefits of both by using them together.
The traditional configuration for this combination is to configure Nginx to the front end of Apache as a reverse proxy server. This enables Nginx to handle all requests from clients. This is thanks to the fast processing power of Nginx, which can process a very large number of connections simultaneously.
For Nginx to be good at static content, files are quickly and directly sent to the client. For dynamic content, such as PHP files, Nginx will send the request to Apache, which can process the request and render the results. Nginx can then send the results back to the client.
This setup works fine in most cases. Because this makes Nginx work like a sorting machine, Nginx handles all requests and forwards the ones it can’t handle. By reducing the number of requests Apache processes, Nginx can reduce the blocking that occurs when Apache processes or threads are occupied.
This configuration also allows you to add additional back-end servers to scale servers as needed. Nginx can be easily configured to forward requests to server pools, which can improve server performance and fault tolerance.
conclusion
As you can see, Apache and Nginx are powerful, flexible server software. Which server is best depends on the specific needs of your application services and the results of testing them under the conditions you want them to operate under.
There are many differences that precede the two servers, and the existence of these differences can really affect performance, load, and the time cost of configuring the application to run. However, this is a series of trade-offs that should not be arbitrarily determined. Finally, there is no one-size-fits-all Web server, so choose the right solution for your project.
This is the first time for me to translate English documents. I can’t find appropriate Chinese expressions for many words, and there may be some professional and technical words that don’t correspond accurately with Chinese technical words. Please correct me more.