Changes with nginx 1.7.10 10 Feb 2015
*) Feature: the "use_temp_path" parameter of the "proxy_cache_path",
"fastcgi_cache_path", "scgi_cache_path", and "uwsgi_cache_path"
*) Feature: the $upstream_header_time variable.
*) Workaround: now on disk overflow nginx tries to write error logs once
a second only.
*) Bugfix: the "try_files" directive did not ignore normal files while
Thanks to Damien Tournoud.
*) Bugfix: alerts "sendfile() failed" if the "sendfile" directive was
used on OS X; the bug had appeared in 1.7.8.
*) Bugfix: alerts "sem_post() failed" might appear in logs.
*) Bugfix: nginx could not be built with musl libc.
Thanks to James Taylor.
*) Bugfix: nginx could not be built on Tru64 UNIX.
Thanks to Goetz T. Fischer.
Documentating myself on proper benchmarking, I ran into the following page:
Their conclusion is that their product is the best of all. Well, 'of
course' one might say... ;o)
What surprised me most that they claim to use less resources AND perform
better. That particularly strikes me because usually ot favor one side, you
take blows on the other one.
To me, the problem of such tests is that they are a mix of
realistic/unrealistic behaviors, the first being invoked to justify useful
conclusions, the latter to make a specific environment so that features
from the Web server (as opposed to other components of the infrastructure)
They are arrogant enough to claim theirs is bigger and paranoid enough to
call almost every other benchmark biased or coming from haste/FUD
campaigns. That is only OK if they are as pure as the driven snow...
I need expert eyes of yours to determine to which end those claims are
- Is their nginx configuration <http://gwan.com/source/nginx.conf> suitable
for valid benchmark results?
- Why is your wrk test tool built in such way in pre-establishes TCP?
- Why is nginx pre-allocating resources so its memory footprint is large
when connections are pre-established? I thought nginx event-based system
was allocating resources on-the-fly, as G-WAN seems to be doing it. (cf.
'The (long) story of Nginx's "wrk"' section)
- Why is wrk (in G-WAN's opinion) 'too slow under 10,000 simultaneous
connections'? (cf. 'The (long) story of Nginx's "wrk"' section)
I am starting to play with some benchmarking tools.
Following Konstantin advice (video from the last user conference ;o) ), I
am avoiding ab.
After a few runs, I notice I get some 'Socket errors' of diffent types:
connect and timeout.
How do I get details about them? Nothing seems to pop up in system logs and
there seem to be no log file for wrk.
I am using nginx as a reverse proxy to a Ruby on Rails application using the
unicorn server on multiple load-balanced application servers. This
configuration allows many HTTP requests to be serviced in parallel. I'll
call the total number of parallel requests that can be serviced 'P', which
is the same as the number of unicorn processes running on the application
I have many users accessing the nginx server and I want to ensure that no
single user can consume too much (or all) of the resources. There are
existing plugins for this type of thing: limit_conn and limit_req. The
problem is that it looks like these plugins are based upon the request rate
(i.e. requests per second). This is a less than ideal way to limit resources
because the rate at which requests are made does not equate to the amount of
load the user is putting on the system. For example, if the requests being
made are simple (and quick to service) then it might be OK for a user to
make 20 per second. However, if the requests are complex and take a longer
time to service then we may not want a user to be able to make more than 1
of these expensive requests per second. So it is impossible to choose a rate
that allows many quick requests, but few slow ones.
Instead of limiting by rate, it would be better to limit the number of
*parallel* requests a user can make. So if the total system can service P
parallel requests we would limit any one user to say P/10 requests. So from
the perspective of any one user our system appears to have 1/10th of the
capacity that it really does. We don't need to limit the capacity to
P/number_of_users because in practice most users are inactive at any point
in time. We just need to ensure that no matter how many requests, fast or
slow, that one user floods the system with, they can't consume all of the
resources and so impact other users.
Note that I don't want to return a 503 error message to a user who tries to
make more than P/10 requests at once. I just want to queue the next request
so that it will eventually execute, just more slowly.
I can't find any existing plugin for Nginx that does this. Am I missing
I am planning to write a plugin that will allow me to implement resource
limits in this way. But I am curious if anyone can see a hole in this logic,
or an alternative way to achieve the same thing.
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,256517,256517#msg-256517
I have a domain setup with SSL and I am trying to get HSTS headers working.
I have done this in NGINX before with no problem. On this new domain I can't
seem to get HSTS working properly. Not sure what I am doing wrong.
I have the following in the server block for the SSL server:
add_header Strict-Transport-Security "max-age=31536000;";
When I run "curl -s -D- https://my.domain.net/ | grep Strict"
I receive the following:
>From all the reading I've done trying to figure this out, my impression is
that with the add_header in the server directive, that will override any
previous declaration (there are none). Is that correct?
I grep'ed my entire /etc directory and there is only one instance of
"max-age" and that is in my ssl server config, with one year (31536000
seconds). So no where on this system, which was just built, and only
accessed by me, is there any reference to HSTS with max-age=0. There is only
one config in sites-enabled, and that is for my.domain.net. There is a port
80 config with a return 301 statement to permanently redirect to the SSL
My nginx version is 1.6.2, on Ubuntu 14.04 LTS.
I have been unable to find any help on the web for where the invalid
(max-age=0) could be coming from. When testing on ssllabs they report the
max-age=0 header. When running the curl statement above on my local network
I show the above output.
I'm not sure where to go from here trying to figure this out. There is
nothing in the NGINX error log, I wouldn't expect anything as NGINX restarts
with no issues.
Thanks for reading!
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,256508,256508#msg-256508
I am happy to announce the new formal release, 22.214.171.124, of the OpenResty bundle:
The highlights of this release are
1. the SSL/TLS support in the websocket client of lua-resty-websocket.
2. an enhanced version of "resty" command-line utility supporting user
command-line arguments and some more handy options.
Special thanks go to all our contributors and users for making this happen!
Below is the complete change log for this release, as compared to the
last formal release (126.96.36.199):
* bundled the "resty" command-line utility (version 0.01) from the
resty-cli project: https://github.com/openresty/resty-cli
* bugfix: the resty utility could not start when the nginx was
built with "./configure --conf-path=PATH" where "PATH" was
not "conf/nginx.conf". thanks Zhengyi Lai for the report.
* feature: added support for user-supplied arguments which the
user Lua scripts can access via the global Lua table "arg",
just as in the "lua" and "luajit" command-line utilities.
thanks Guanlan Dai for the patch.
* feature: added new command-line option "--nginx=PATH" to
allow the user to explicitly specify the underlying nginx
executable being invoked by this script. thanks Guanlan Dai
for the patch.
* feature: added support for multiple "-I" options to specify
more than one user library search paths. thanks Guanlan Dai
for the patch.
* feature: print out resty's own version number when the -V
option is specified.
* feature: resty: added new options "--valgrind" and
* upgraded the ngx_set_misc module to 0.28.
* feature: added the set_base32_alphabet config directive to
allow the user to specify the alphabet used for base32
encoding/decoding. thanks Vladislav Manchev for the patch.
* bugfix: set_quote_sql_str: we incorrectly escaped 0x1a to
"\z" instead of "\Z".
* change: the old set_misc_base32_padding directive is now
deprecated; use set_base32_padding instead.
* upgraded the ngx_lua module to 0.9.14.
* bugfix: ngx.re.gsub/ngx.re.sub incorrectly swallowed the
character right after a 0-width match that happens to be the
last match. thanks Guanlan Dai for the patch.
* bugfix: tcpsock:setkeepalive(): we did not check "NULL"
connection pointers properly, which might lead to
segmentation faults. thanks Yang Yue for the report.
* bugfix: ngx.quote_str_str() incorrectly escaped "\026" to
"\z" while "\Z" is expected. thanks laodouya for the
* bugfix: ngx.timer.at: fixed a small memory leak in case of
running out of memory (which should be extremely rare
* optimize: minor optimizations in timers.
* feature: added the Lua global variable "__ngx_cycle" which
is a lightuserdata holding the current "ngx_cycle_t"
pointer, which may simplify some FFI-based Lua extensions.
* doc: added a warning for the "share_all_vars" option for
* upgraded the lua-resty-core library to 0.1.0.
* bugfix: resty.core.regex: data corruptions might happen when
recursively calling ngx.re.gsub via the user replacement
function argument because of incorrect reusing a globally
shared captures Lua table. thanks James Hurst for the
* bugfix: ngx.re.gsub: garbage might get injected into gsub
result when "ngx.*" API functions are called inside the user
callback function for the replacement. thanks James Hurst
for the report.
* feature: resty.core.base: added the "FFI_BUSY" constant for
* upgraded the lua-resty-lrucache library to 0.04.
* bugfix: resty.lrucache.pureffi: set(): it did not update to
the new value at all if the key had an existing value
(either stale or not). thanks Shuxin Yang for the patch.
* upgraded the lua-resty-websocket library to 0.05.
* feature: resty.websocket.client: added support for SSL/TLS
connections (i.e., the "wss://" scheme). thanks Vladislav
Manchev for the patch.
* doc: mentioned the bitop library dependency when using the
standard Lua 5.1 interpreter (this is not needed for LuaJIT
because it is already built in). thanks Laurent Arnoud for
* upgraded LuaJIT to v2.1-20150120:
* imported Mike Pall's latest changes:
* bugfix: don't compile "IR_RETF" after "CALLT" to ff with
* bugfix: fix "BC_UCLO"/"BC_JMP" join optimization in Lua
* bugfix: fix corner case in string to number conversion.
* bugfix: x86: fix argument checks for "ipairs()"
* bugfix: gracefully handle "lua_error()" for a suspended
* x86/x64: Drop internal x87 math functions. Use libm
* x86/x64: Call external symbols directly from interpreter
code. (except for ELF/x86 PIC, where it's easier to use
* ARM: Minor interpreter optimization.
* x86: Minor interpreter optimization.
* PPC/e500: Drop support for this architecture.
* MIPS: Fix excess stack growth in interpreter.
* PPC: Fix excess stack growth in interpreter.
* ARM: Fix excess stack growth in interpreter.
* ARM: Fix write barrier check in "BC_USETS".
* ARM64: Add build infrastructure and initial port of
* OpenBSD/x86: Better executable memory allocation for
* bugfix: the "ngx_http_redis" module failed to compile when the
"ngx_gzip" module was disabled. thanks anod221 for the report.
The HTML version of the change log with lots of helpful hyper-links
can be browsed here:
OpenResty (aka. ngx_openresty) is a full-fledged web application
server by bundling the standard Nginx core, Lua/LuaJIT, lots of 3rd-party Nginx
modules and Lua libraries, as well as most of their external
dependencies. See OpenResty's homepage for details:
We have run extensive testing on our Amazon EC2 test cluster and
ensured that all the components (including the Nginx core) play well
together. The latest test report can always be found here:
And we have always been running the latest OpenResty in CloudFlare's
global CDN network for years.
We're using Debian 7.x (Wheezy), and because I rather have the latest
version of nginx than the stock or backports version, I decided to add
I grabbed the lines from http://nginx.org/en/linux_packages.html and
added them to /etc/apt/sources.list.d/nginx.list as follows:
deb http://nginx.org/packages/debian/ wheezy nginx
deb-src http://nginx.org/packages/debian/ wheezy nginx
This works fine after adding the key, however, after running apt-get
update, it displays:
Maintainer: Sergey Budnevitch <sb(a)nginx.com>
Even though the pool of the repository only contains 1.7.9:
And, when I look in the Packages list obtained from your repo, I see the
root@webtv4:/var/lib/apt/lists# grep -A1 'Package:' nginx*
Could you please update the package listing of the Debian repository so
that we may enjoy the latest version with all of its wonderful features? :)