What is NGINX?

In the previous posts, we went over an overview of the Apache Web Server, how it functions, its place in history, and how Sumo Logic helps in sorting through the numerous logs provided in Apache. Apache Access and Error logs are integral to understanding the traffic patterns and issues users face when accessing your web applications. Sumo Logic helps administrators parse through these logs, isolate issues, and determine the root causes of errors. Sumo Logic also provides invaluable insight for business and product development teams in order to gauge user interaction and navigation patterns.

Intro to NGINX

Today we will be covering NGINX, an open source web server and the main alternative and competitor to the Apache HTTP Server. NGINX has been gaining in popularity since its inception and is used across a wide spectrum of applications for web serving, reverse proxying, caching, load balancing, media streaming, and much more.

Quick History of NGINX

In 2002, web developers across the internet were tasked to tackle the challenge of engineering a web server capable of handling ten thousand concurrent web connections--dubbed as C10k--as what would be considered a required benchmark of the modern web. As a response, software engineer Igor Sysoev released the first public version of NGINX, which relies on an asynchronous, event-driven architecture. This means that unlike Apache HTTP Server, NGINX handles multiple processes and threads for requests in one worker process as opposed to dedicated processes or threads, which Apache is known for.

NGINX vs Apache

There was a time when Apache reigned supreme without question and everything else was far behind. Today, in 2019, the web server landscape has changed, and depending on who you ask, NGINX and Microsoft's IIS are neck and neck for second place, depending on the specific function of your server. Either way, Apache is losing ground quickly as web applications and their functions are becoming more dynamic and specific to their cause.

A decade ago, when web applications and servers were nearly all the same, Apache could handle almost everything you needed. But as the web grew and different needs were required, NGINX began to fill a need that Apache couldn’t. Apache is great for shared hosting of multiple sites, but NGINX is showing its strength and dominance for dynamic content, elaborate features, and pure flexibility in an ever-changing landscape of web content.

Just like Apache and the LAMP stack, NGINX has become popular by offering itself as part of a LEMP solution for software developers (with the E standing for NGINX with its phonetic spelling, ‘engine-x’). This Linux, NGINX, MySQL, and PHP/Python stack that mirrors the classic web LAMP stack has grown in usage and popularity. While Apache and the LAMP stack is still a widely-used solution, you may want to consider NGINX and LEMP for your web application, depending on your use case.

How is NGINX Different than Apache?

NGINX came into the server landscape after Apache, therefore its developers had the benefit of being aware of web serving issues and technical limitations that Apache had..

Directly addressing these issues and limitationsNGINX relies on event-driven, asynchronous, single-threaded architecture. By utilizing the underlying power of modern operating systems like Linux and Unix, NGINX is able to serve at least 10x more (and often 100–1000x more) requests per server compared to Apache. Efficiently optimizing the use of memory and CPU, NGINX is capable of rapidly scaling to provide more users connections while also providing better bandwidth, all while being less of a resource hog when compared to other modern operating systems.

NGINX handles requests differently than Apache which makes NGINX suitable for a more dynamic environment with varied roles. Some of the most popular use-case scenarios for NGINX in a web application besides serving dynamic web content include: use as a reverse proxy server for HTTPS and other TCP protocols, load balancing for efficient traffic distribution, and HTTP caching.

While it’s totally doable for Apache to be used as a load balancer, Apache is known for its power and durability while NGINX is known for speed, responsiveness, and resource efficiency. Therefore it’s much more common to have NGINX as a reverse proxy with Apache as the backend server.

How Does NGINX Process Dynamic Requests?

You can run benchmark tests all day but real world use-cases are a much better way to determine how servers behave in the wild. We can take a look at static versus dynamic content, and how each server handles both requests.

Apache - Part of what makes Apache great is its modular configurability with MPMs or “multi-processing modules”. Apache is fully capable of handling static and dynamic content through conventional file-based methods and also through its MPM workers. By embedding the required language processor within each worker instance, dynamic content can be executed within the server without relying on external components

NGINX - On its own, NGINX is not capable of processing dynamic content natively. In order to handle a scripting language such as PHP, NGINX must pass the request to an external processor that handles the execution of the script and then it waits for the content to be sent back, rendered and ready to be served to the end user. This means admins need to configure communication via the protocols NGINX knows to use like http, FastCGI, SCGI, and uWSGI.

Since dynamic interpreters are external and not integrated with the worker processes, they are only used for serving dynamic content while static content can be served directly. This gives NGINX its reputation of speed and responsiveness.

Conclusion

In this intro to NGINX, we covered a brief history of the NGINX server, how it came to be, its place within the server landscape and also the benefits of NGINX over Apache. While both types of servers are powerful in their own right, it’s important to recognize specific use-case scenarios so developers and administrators can be better equipped when making infrastructure decisions.

In Part 2 of the NGINX blog series, we’ll be taking a deeper dive into configuration management, log files, error pages, and the different types of modules that can be used to enhance your web application and server architecture in NGINX. Stay tuned.