Few days back I was trying to evaluate the performance of upstream
keepalive feature for a website when I noticed a rather unexpected
behaviour. It would be help me understand what's going on in the test.
Here's what I did:
1. Setup httperf to run a session load. This basically means that a text
file with different urls is supplied to httperf. httperf sends all the
requests in bursts spaced by a sec towards nginx.
2. Tcpdump is run on the machine
3. Before the tests begin, cache is cleared and nginx restarted
4. Test is repeated with httperf "replaying" the requests 1 time first, and
re-run with repeat count 4 to account for setup of connections/cache
5. All the steps are repeated once without keepalive and with keepalive 512;
SessionKeep aliveConns upstreamConn TimeUnique upstream hostsReqs upstreamAvg
time to 1st byteMax upstream conn reuseClient conns (1)Client reqs (1)Client
replies (1)Testdur (1)Client connsClient reqsClient repliesTestdurmy-site148
* First row with keepalive, second row without keepalive.
* With keepalive, number of connections upstream (as seen in tcpdump) is
48. Note that my-site has multiple (19 - unique upstream hosts) subdomains,
each of which is individually configured. Without keepalive 192 connections
* Total time spent establishing connections is 8.3 vs 20.7
* Latency is ~0.15secs
All these are as expected, test duration however goes from 78 -> 71 secs.
An *increase* in the time for test to complete.
As the number of unique upstream increases, the time increases further.
This wasnt something that I could explain. Please help me understand, is it
a bug in the system?
nginx version: nginx/1.1.18
built by gcc 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
TLS SNI support enabled
configure arguments: --without-http_ssi_module --without-http_geo_module
--with-http_ssl_module --with-debug --without-http_rewrite_module
proxy_cache_path /tmp/cache levels=1:2 keys_zone=my-cache:8m
Highly appreciate any help on this.
In svn r2758, proxy_ignore_client_abort is ignored when case where
proxy_cache or proxy_store is enabled. What was the reason for this,
compared to letting it be controlled using proxy_ignore_client_abort?
I reverted the patch and proxy_cache appears to work as expected with
proxy_ignore_client_abort set to on and off, but I'm curious to know if
there are other side effects.
Author: is <is@73f98a42-aea0-e011-b76d-00259023448c>
Date: Mon Apr 27 11:20:55 2009 +0000
get a full response if the response is cacheable or storable even
a client has closed connection prematurely
There is a bug in ngx_http_image_resize function from
ngx_http_image_filter_module with incorrect calculation of new image
sizes after resizing with crop in case of original image is capable to
resize with preservation of original proportions (i.e. crop is not
required). For example, resizing image with original sizes of 360x203
to 304x171 with crop, will surprisingly give us resized and cropped
image with sizes of 303x171, though resizing the same image without
crop will give us correct image with sizes of 304x171.
Attached image_filter_crop.patch fixes this undesired behavior.
In the same time i've found that algorithm for calculation of new
image sizes in both resize and crop cases could be generalized.
Attached image_filter.patch uses this idea and reduces number of
duplicated source lines (also includes bugfix from