What is nginx written in

Because Nginx is asynchronous , each request can be executed by the worker concurrently without blocking other requests. Some common features seen in Nginx include: Reverse proxy with caching. On 12 December , it was reported that the Moscow offices of Nginx Inc. You can use Nginx in front of Apache as a server proxy as shown in the image below. This takes advantage of Nginx fast processing speed and ability to establish large no, of connection simultaneously.

For static connections, Nginx will serve the files quickly to the clients. The Bad Gateway error is an HTTP status code which indicates that one server on the internet received an invalid response from another server. What language is Nginx written in? Category: technology and computing web hosting.

How do you pronounce nginx? Does nginx support Python? How do I start nginx? Log into your ve Server via SSH as the root user. Which is better Nginx or Apache? Why is Nginx used? Who uses nginx? Why Nginx is faster than Apache? Can I use nginx for free? How old is nginx? What is meant by proxy server? Who made Nginx? Igor Sysoev. Currently nginx is the second most popular open source web server on the Internet. These days the Internet is so widespread and ubiquitous it's hard to imagine it wasn't exactly there, as we know it, a decade ago.

It has greatly evolved, from simple HTML producing clickable text, based on NCSA and then on Apache web servers, to an always-on communication medium used by more than 2 billion users worldwide. With the proliferation of permanently connected PCs, mobile devices and recently tablets, the Internet landscape is rapidly changing and entire economies have become digitally wired. Online services have become much more elaborate with a clear bias towards instantly available live information and entertainment.

Security aspects of running online business have also significantly changed. Accordingly, websites are now much more complex than before, and generally require a lot more engineering efforts to be robust and scalable.

One of the biggest challenges for a website architect has always been concurrency. Since the beginning of web services, the level of concurrency has been continuously growing. It's not uncommon for a popular website to serve hundreds of thousands and even millions of simultaneous users. A decade ago, the major cause of concurrency was slow clients—users with ADSL or dial-up connections.

Nowadays, concurrency is caused by a combination of mobile clients and newer application architectures which are typically based on maintaining a persistent connection that allows the client to be updated with news, tweets, friend feeds, and so on. Another important factor contributing to increased concurrency is the changed behavior of modern browsers, which open four to six simultaneous connections to a website to improve page load speed. To illustrate the problem with slow clients, imagine a simple Apache-based web server which produces a relatively short KB response—a web page with text or an image.

Essentially, the web server would relatively quickly pull KB of content, and then it would be busy for 10 seconds slowly sending this content to the client before freeing its connection. Now imagine that you have 1, simultaneously connected clients who have requested similar content.

If only 1 MB of additional memory is allocated per client, it would result in MB about 1 GB of extra memory devoted to serving just clients KB of content. In reality, a typical web server based on Apache commonly allocates more than 1 MB of additional memory per connection, and regrettably tens of kbps is still often the effective speed of mobile communications. Although the situation with sending content to a slow client might be, to some extent, improved by increasing the size of operating system kernel socket buffers, it's not a general solution to the problem and can have undesirable side effects.

With persistent connections the problem of handling concurrency is even more pronounced, because to avoid latency associated with establishing new HTTP connections, clients would stay connected, and for each connected client there's a certain amount of memory allocated by the web server. Consequently, to handle the increased workloads associated with growing audiences and hence higher levels of concurrency—and to be able to continuously do so—a website should be based on a number of very efficient building blocks.

While the other parts of the equation such as hardware CPU, memory, disks , network capacity, application and data storage architectures are obviously important, it is in the web server software that client connections are accepted and processed. Thus, the web server should be able to scale nonlinearly with the growing number of simultaneous connections and requests per second. Apache, the web server software that still largely dominates the Internet today, has its roots in the beginning of the s.

Originally, its architecture matched the then-existing operating systems and hardware, but also the state of the Internet, where a website was typically a standalone physical server running a single instance of Apache. By the beginning of the s it was obvious that the standalone web server model could not be easily replicated to satisfy the needs of growing web services.

Although Apache provided a solid foundation for future development, it was architected to spawn a copy of itself for each new connection, which was not suitable for nonlinear scalability of a website. Eventually Apache became a general purpose web server focusing on having many different features, a variety of third-party extensions, and universal applicability to practically any kind of web application development.

However, nothing comes without a price and the downside to having such a rich and universal combination of tools in a single piece of software is less scalability because of increased CPU and memory usage per connection.

Thus, when server hardware, operating systems and network resources ceased to be major constraints for website growth, web developers worldwide started to look around for a more efficient means of running web servers. Around ten years ago, Daniel Kegel, a prominent software engineer, proclaimed that "it's time for web servers to handle ten thousand clients simultaneously" and predicted what we now call Internet cloud services. Kegel's C10K manifest spurred a number of attempts to solve the problem of web server optimization to handle a large number of clients at the same time, and nginx turned out to be one of the most successful ones.

Aimed at solving the C10K problem of 10, simultaneous connections, nginx was written with a different architecture in mind—one which is much more suitable for nonlinear scalability in both the number of simultaneous connections and requests per second. The end result is that even as load increases, memory and CPU usage remain manageable.

When the first version of nginx was released, it was meant to be deployed alongside Apache such that static content like HTML, CSS, JavaScript and images were handled by nginx to offload concurrency and latency processing from Apache-based application servers. Over the course of its development, nginx has added integration with applications through the use of FastCGI, uswgi or SCGI protocols, and with distributed memory object caching systems like memcached. Other useful functionality like reverse proxy with load balancing and caching was added as well.

These additional features have shaped nginx into an efficient combination of tools to build a scalable web infrastructure upon. In February , the Apache 2. Although this latest release of Apache has added new multi-processing core modules and new proxy modules aimed at enhancing scalability and performance, it's too soon to tell if its performance, concurrency and resource utilization are now on par with, or better than, pure event-driven web servers.

It would be very nice to see Apache application servers scale better with the new version, though, as it could potentially alleviate bottlenecks on the backend side which still often remain unsolved in typical nginx-plus-Apache web configurations.

Handling high concurrency with high performance and efficiency has always been the key benefit of deploying nginx. However, there are now even more interesting benefits. In the last few years, web architects have embraced the idea of decoupling and separating their application infrastructure from the web server.

With recent flavors of development kits and programming languages gaining wide use, more and more companies are changing their application development and deployment habits. The first lines of nginx were written in In it was released to the public under the two-clause BSD license.

The number of nginx users has been growing ever since, contributing ideas, and submitting bug reports, suggestions and observations that have been immensely helpful and beneficial for the entire community. The nginx codebase is original and was written entirely from scratch in the C programming language.

A few words about the Windows version of nginx. While nginx works in a Windows environment, the Windows version of nginx is more like a proof-of-concept rather than a fully functional port. There are certain limitations of the nginx and Windows kernel architectures that do not interact well at this time.

The known issues of the nginx version for Windows include a much lower number of concurrent connections, decreased performance, no caching and no bandwidth policing. Future versions of nginx for Windows will match the mainstream functionality more closely. Depending on the application, it can be very inefficient in terms of memory and CPU consumption.

Spawning a separate process or thread requires preparation of a new runtime environment, including allocation of heap and stack memory, and the creation of a new execution context.

Additional CPU time is also spent creating these items, which can eventually lead to poor performance due to thread thrashing on excessive context switching. All of these complications manifest themselves in older web server architectures like Apache's.

This is a tradeoff between offering a rich set of generally applicable features and optimized usage of server resources. From the very beginning, nginx was meant to be a specialized tool to achieve more performance, density and economical use of server resources while enabling dynamic growth of a website, so it has followed a different model. It was actually inspired by the ongoing development of advanced event-based mechanisms in a variety of operating systems.

What resulted is a modular, event-driven, asynchronous, single-threaded, non-blocking architecture which became the foundation of nginx code. Connections are processed in a highly efficient run-loop in a limited number of single-threaded processes called worker s. Within each worker nginx can handle many thousands of concurrent connections and requests per second.

The nginx worker code includes the core and the functional modules. The core of nginx is responsible for maintaining a tight run-loop and executing appropriate sections of modules' code on each stage of request processing. Modules constitute most of the presentation and application layer functionality. Modules read from and write to the network and storage, transform content, do outbound filtering, apply server-side include actions and pass the requests to the upstream servers when proxying is activated.

At this time, nginx doesn't support dynamically loaded modules; i. However, support for loadable modules and ABI is planned for the future major releases. More detailed information about the roles of different modules can be found in Section The goal is to provide as many hints to the operating system as possible, in regards to obtaining timely asynchronous feedback for inbound and outbound traffic, disk operations, reading from or writing to sockets, timeouts and so on.

A high-level overview of nginx architecture is presented in Figure As previously mentioned, nginx doesn't spawn a process or thread for every connection. Instead, worker processes accept new requests from a shared "listen" socket and execute a highly efficient run-loop inside each worker to process thousands of connections per worker.

There's no specialized arbitration or distribution of connections to the worker s in nginx; this work is done by the OS kernel mechanisms. Upon startup, an initial set of listening sockets is created.

The run-loop is the most complicated part of the nginx worker code. It includes comprehensive inner calls and relies heavily on the idea of asynchronous task handling. Asynchronous operations are implemented through modularity, event notifications, extensive use of callback functions and fine-tuned timers. Overall, the key principle is to be as non-blocking as possible. The only situation where nginx can still block is when there's not enough disk storage performance for a worker process.

Because nginx does not fork a process or thread per connection, memory usage is very conservative and extremely efficient in the vast majority of cases. What nginx does is check the state of the network and storage, initialize new connections, add them to the run-loop, and process asynchronously until completion, at which point the connection is deallocated and removed from the run-loop.

Combined with the careful use of syscall s and an accurate implementation of supporting interfaces like pool and slab memory allocators, nginx typically achieves moderate-to-low CPU usage even under extreme workloads. Because nginx spawns several worker s to handle connections, it scales well across multiple cores.

Generally, a separate worker per core allows full utilization of multicore architectures, and prevents thread thrashing and lock-ups. There's no resource starvation and the resource controlling mechanisms are isolated within single-threaded worker processes. As a result, server resources are utilized more efficiently with the workload shared across several workers.

With some disk use and CPU load patterns, the number of nginx worker s should be adjusted. The rules are somewhat basic here, and system administrators should try a couple of configurations for their workloads.

Some engineers choose the number of worker s based on the number of individual storage units instead, though efficiency of this approach depends on the type and configuration of disk storage.

Most notably, combinations of options like sendfile and AIO typically produce a lot of headroom for disk performance. An nginx installation should be planned based on the data set, the amount of memory available for nginx, and the underlying storage architecture.

Another problem with the existing worker model is related to limited support for embedded scripting. For one, with the standard nginx distribution, only embedding Perl scripts is supported.

There is a simple explanation for that: the key problem is the possibility of an embedded script to block on any operation or exit unexpectedly. Both types of behavior would immediately lead to a situation where the worker is hung, affecting many thousands of connections at once.

More work is planned to make embedded scripting with nginx simpler, more reliable and suitable for a broader range of applications. There are also a couple of special purpose processes, specifically a cache loader and cache manager.

All processes are single-threaded in version 1. All processes primarily use shared-memory mechanisms for inter-process communication. The master process is run as the root user. The cache loader, cache manager and worker s run as an unprivileged user. The worker processes accept, handle and process connections from clients, provide reverse proxying and filtering functionality and do almost everything else that nginx is capable of.

In regards to monitoring the behavior of an nginx instance, a system administrator should keep an eye on worker s as they are the processes reflecting the actual day-to-day operations of a web server. The cache loader process is responsible for checking the on-disk cache items and populating nginx's in-memory database with cache metadata.

Essentially, the cache loader prepares nginx instances to work with files already stored on disk in a specially allocated directory structure. It traverses the directories, checks cache content metadata, updates the relevant entries in shared memory and then exits when everything is clean and ready for use. The cache manager is mostly responsible for cache expiration and invalidation. It stays in memory during normal nginx operation and it is restarted by the master process in the case of failure.

Caching in nginx is implemented in the form of hierarchical data storage on a filesystem. Cache keys are configurable, and different request-specific parameters can be used to control what gets into the cache. Cache keys and cache metadata are stored in the shared memory segments, which the cache loader, cache manager and worker s can access. Currently there is not any in-memory caching of files, other than optimizations implied by the operating system's virtual filesystem mechanisms.

Each cached response is placed in a different file on the filesystem. The hierarchy levels and naming details are controlled through nginx configuration directives.

When a response is written to the cache directory structure, the path and the name of the file are derived from an MD5 hash of the proxy URL. The process for placing content in the cache is as follows: When nginx reads the response from an upstream server, the content is first written to a temporary file outside of the cache directory structure.

When nginx finishes processing the request it renames the temporary file and moves it to the cache directory. If the temporary files directory for proxying is on another file system, the file will be copied, thus it's recommended to keep both temporary and cache directories on the same file system.

It is also quite safe to delete files from the cache directory structure when they need to be explicitly purged. There are third-party extensions for nginx which make it possible to control cached content remotely, and more work is planned to integrate this functionality in the main distribution. His main insight was that a scalable configuration system is essential for a web server. The main scaling problem was encountered when maintaining large complicated configurations with lots of virtual servers, directories, locations and datasets.

In a relatively big web setup it can be a nightmare if not done properly both at the application level and by the system engineer himself. As a result, nginx configuration was designed to simplify day-to-day operations and to provide an easy means for further expansion of web server configuration. The main configuration file is usually called nginx. To keep it uncluttered, parts of the configuration can be put in separate files which can be automatically included in the main one.

However, it should be noted here that nginx does not currently support Apache-style distributed configurations i. All of the configuration relevant to nginx web server behavior should reside in a centralized set of configuration files. The configuration files are initially read and verified by the master process.

A compiled read-only form of the nginx configuration is available to the worker processes as they are forked from the master process. Configuration structures are automatically shared by the usual virtual memory management mechanisms.

Contexts never overlap. For instance, there is no such thing as putting a location block in the main block of directives. Also, to avoid unnecessary ambiguity there isn't anything like a "global web server" configuration. In a private conversation, Sysoev said, "Locations, directories, and other blocks in the global server configuration are the features I never liked in Apache, so this is the reason why they were never implemented in nginx.

Configuration syntax, formatting and definitions follow a so-called C-style convention. This particular approach to making configuration files is already being used by a variety of open source and commercial software applications.

By design, C-style configuration is well-suited for nested descriptions, being logical and easy to create, read and maintain, and liked by many engineers. C-style configuration of nginx can also be easily automated. While some of the nginx directives resemble certain parts of Apache configuration, setting up an nginx instance is quite a different experience.

For instance, rewrite rules are supported by nginx, though it would require an administrator to manually adapt a legacy Apache rewrite configuration to match nginx style.

The implementation of the rewrite engine differs too.