Apache is the most commonly used web server software on the Internet, and for good reason.
Its long history, general reliability, thorough documentation and active support community have helped it grow to include support for nearly anything a web developer can think to throw at it. But Apache’s universal support has not come without some trade-offs.
Why Apache Alone May Not Meet Your Needs
Apache excels at serving web pages, but its resource requirements (particularly memory) increase as it’s given more to do, thanks to the way Apache manages processes. Apache’s process management is governed by its Multi-Processing Module (MPM). The most common are prefork, worker, and event.
Each time a new request comes in, Apache creates a new process to handle it.
- In prefork mode, each process contains a single thread (the code which runs inside of a process).
- In worker mode, each process can contain multiple threads, each handling a single connection.
- In event mode, each process can contain multiple threads, but each is able to handle more than one connection at a time.
Regardless of the MPM, new processes still are being created to handle new incoming requests (although worker creates fewer than prefork, and event creates fewer than worker).
As requests keep coming in and new processes are created to handle them, CPU and memory usage continue to increase. That drives up load, slows the server down, and ultimately (should the amount of incoming requests far exceed the server’s capabilities) could cause it to become unresponsive. With Apache, scaling up typically requires adding RAM or CPU cores to cope with greatly increased traffic.
And that’s the essential problem Nginx aims to solve: Scalability.
Unlike Apache, Nginx does not create new processes to handle incoming requests. It runs with a set number of processes, typically only one per CPU core, and each of its few processes uses a single thread to handle many requests (potentially thousands) at the same time.
Because of this, Nginx’s resource requirements don’t tend to increase with incoming requests as do Apache’s. And thanks to its small footprint, it’s also able to do the job considerably faster.
One Server’s Weakness Is Another’s Strength
While Nginx’s processes management can be much more efficient and it can serve pages at lightning speed, it’s important to note that the potential performance gains with Nginx are most dramatic when serving static content.
Unless your site is mostly comprised of static pages, you may decide that there’s not a tremendous amount to be gained by switching from Apache to Nginx outright, given that you’d still need to rely on another application to serve the dynamic content.
And that’s the beauty of using the more-powerful Apache and the more-nimble Nginx together.
In terms of resource usage, Apache doesn’t really care what type of content it’s serving. Processes are created and threads are spun off based only on the number of incoming requests. That makes it somewhat less than ideal for serving extremely large amounts of small, static resources.
By allowing Nginx to serve the static content and pass requests for dynamic content to Apache, you can (for a small amount of overhead up front) effectively eliminate the drain on resources that otherwise would have been caused by having Apache serve all that static content.
Meanwhile, Nginx is caching as it serves, making future requests that much faster still.
This setup, in which Nginx listens on the standard web port (typically 80) and transparently passes requests to the appropriate server, is called a reverse proxy configuration.
Depending on your site’s composition and the number of static resources served, you could find that pairing Nginx and Apache can yield dramatic results.
- Apache, assuming it already is installed and running, would need to be configured to run on another port.
- After switching the Apache port, sites on the server would not be accessible at their normal URLs until Nginx is installed, properly configured, and running.
- Nginx handles virtual hosts (vhosts) differently than Apache, and each existing virtual host entry would need to be recreated for Nginx.
- Some control panel software, such as cPanel/WHM, does not officially support Nginx (although WHM/cPanel plugins are available).
- The installation, configuration, troubleshooting and maintenance of Nginx is not supported by Liquid Web on any platform; do not attempt to install any software or modify any configuration files unless you have fully researched the process and know how to address any potential issues that may arise.
Find More Information in Our Knowledge Base