Announcement NGINX 1.10 and 1.11

Disclaimer: The original article, the translation of which is presented here, serves the purpose of announcing the release of new older versions of the product, telling in general about the versioning policy and successes over the past year. If you are interested in dry technical details, I recommend watching the complete change log , or squeezing it with a brief explanation at the end of the article.

We are pleased to introduce NGINX 1.10 and 1.11. These version numbers denote the stable and mainline branches of the free open issues, over which we will focus our efforts over the next 12 months.

NGINX version 1.10.0 is already out , and the future release of the main branch will be number 1.11.0.

NGINX Versioning System

NGINX, Inc. supports two branches of the well-known web server and NGINX accelerator:

• The odd version (1.11) is our main branch. It is being actively developed, new minor releases (1.11.1, 1.11.2, etc.) are released approximately every 4-6 weeks, regularly providing new opportunities;
• The even version (1.10) is our stable branch. It is intended for users who do not want to be at the forefront of the development of NGINX, and is updated only to correct critical problems. For example, over the last year only one minor update has been released under the stable 1.8 branch.

Every year we declare obsolete the current stable branch and branch off from the main branch a new stable one that will be maintained for the next 12 months:
')
Version 1.8 is no longer supported. Version 1.10 is separated from version 1.9, as a new stable branch, and 1.9 is renumbered in 1.11.

Choose the branch that best meets your requirements. If you want to get all the new features, optimizations and fixes, then you should give preference to the main branch, which (ironically) is generally more reliable than a stable branch. If you want to reduce the number of updates and do not feel the need for any features planned for the next 12 months, then a stable branch is a good choice.

The best of the two approaches has incorporated NGINX Plus , which is based on the main branch, but has a quarterly release cycle and official support from the NGINX team.

Looking back at the work done in NGINX 1.9

Last year was one of the most intense in the history of NGINX. A huge amount of new functionality was included in the main branch. HTTP / 2 , TCP and UDP proxying with balancing , dynamic modules - all this has been added to the free version of the web server for the last 12 months.

Many other features, fixes, and improvements have also been implemented, making the 1.9 series the largest development in recent years. A complete list of such changes can be found in a note to all releases of a branch . The small number of changes that have been ported to the stable 1.8 branch is an indicator of the high standards of quality and reliability that our development team adheres to.

In addition, in 2015, we crossed the significant milestone of NGINX popularity. Although we have no intention to compete and take market share from other web servers, it is nice to see a steady increase in the use of NGINX. And at the moment more than 50% of the 10,000 most loaded sites in the world rely on NGINX to deliver applications and content to their users.

Looking into the bright future of NGINX 1.11

The future NGINX 1.11 series also promises a lot of new and interesting. Work continues on nginScript , an implementation of JavaScript specially tailored to the unique requirements of the NGINX core . We are going to continue to develop the NGINX developer community, thanks in large part to the possibility of creating dynamic modules and the recently published first part of developer documentation . Meeting the needs of modern distributed applications based on microservice architecture also occupies a leading role in our plans, most of which will be announced at our annual conference “nginx.conf” in September 2016 .

As for NGINX Plus

NGINX Plus is a version of NGINX with official technical support and extended functionality that allows it to perfectly cope with the role of the main balancer and content delivery controller (ADC). NGINX Plus is based on the main branch and has a three-month release cycle. The new functionality from the main branch is merged into NGINX Plus and is released after the passage of the full integration testing and combat testing as part of the free version of NGINX:

NGINX Plus is based on the main NGINX branch with added functionality.

The internal version number of NGINX Plus, corresponding to the release from the main branch on which it is based, can be found in the release notes . To see the installed version number, you can run the nginx -v command:

 $ nginx -v nginx version: nginx/1.9.13 (nginx-plus-r9) 

NGINX Plus gives you the perfect balance of the latest, but already tested in battle, features of the free version of NGINX, improved balancing and various additional functionality interesting to commercial users, as well as full 24x7 support and updates from our team of engineers and experts. You can try the NGINX Plus trial version for free for 30 days by filling out the form or contacting us .

---

The list of major innovations in NGINX version 1.10 compared with 1.8:

• Support for dynamic modules. In particular, this makes it possible to decompose the modules into different packages with their dependencies and, if necessary, to reinstall, connect and update them separately. So in our official repositories we already provide a set of individual packages with modules , including the njs module , which allows using JavaScript in configs .
• New stream module for proxying and balancing any TCP and UDP traffic. For example, you can now use NGINX to balance DNS or MySQL servers.
• A new slice module that improves the efficiency of caching large files by splitting them into fragments that can be cached independently.
• The SPDY module has been replaced with the HTTP / 2 module . The latter now also supports unbuffered reading of the request body .
• The sub_filter module has been significantly improved, allowing replacement in the body of the server response. Increased performance, it became possible to use variables as the desired string and replacement string, and now you can set many such lines.
• The reuseport option of the listen directive allows to significantly increase performance on multiprocessor systems in cases of high intensity of new connections. Detailed article about it .
• TCP support in built-in resolver .
• The idempotency of the request methods is now taken into account when selecting another server in case of proxying errors. Behavior is governed by the new non_idempotent option in the proxy_next_upstream , fastcgi_next_upstream , uwsgi_next_upstream and scgi_next_upstream
• Thread pools can now be used to record the response from the backend. Managed by the aio_write directive . Detailed article about what are thread pools, what they are for and how to use them.
• Improved cache manager. It now tracks not only disk space, but also the amount of metadata in shared memory.
• The worker_cpu_affinity directive received automatic mode and support for more than 64 processors.
• The include directive can now be used inside an upstream block .
• Directive proxy_cache_convert_head , which controls the conversion of the HEAD method to GET when caching.
• The nohostname parameter, which prohibits adding the hostname field to the message header when logging to syslog .
• Variable $realip_remote_addr module , which contains the source address of the client.
• The $upstream_connect_time variable that contains the time taken to connect and the TLS handshake (if encryption is used) with the backend.
• The memcached module now supports byte range requests .
• For the upstream block, you can now use shared memory using the zone directive , which, in particular, allows all workflows to have the same idea of ​​the health of proxied servers, but can adversely affect performance.
• Support for shared memory in the version for Windows and, accordingly, all modules that use it.
• In the mail proxy server, it became possible to set different logging parameters using the error_log directive at the mail and server levels.

Previous announcements: NGINX 1.8 / 1.9 and NGINX 1.6 / 1.7 .