Hi,
enclosed you will find an attached changeset, that fixes a ASLR/DEP
problem on windows platforms (example Win 7/2008 x64).
To find shared addr offset with ASLR, we have successful used the same
resp. similar solution on various open source projects (ex.: postgresql
etc.). Also nginx with suggested patch works fine over 5 months in
production on several machines (Win-2k8-R2).
BTW(1): I have interest to fix a problem with multiple workers under
windows (ex.: http://forum.nginx.org/read.php?2,188714,188714#msg-188714
[1]).
@Maxim Dounin: can you possibly give me more information, what you mean
here, resp. what it currently depends on (see
http://forum.nginx.org/read.php?2,188714,212568#msg-212568 [2]).
BTW(2): I would like to fix iocp under windows also. Thanks in advance
for any information about.
P.S. speak fluently russian and german...
Regards,
Serg G. Brester (sebres)
-------------------------
Links:
------
[1] http://forum.nginx.org/read.php?2,188714,188714#msg-188714
[2] http://forum.nginx.org/read.php?2,188714,212568#msg-212568
Hi,
enclosed you will find an attached changeset, that:
- allows to fast use of named location in sub requests, such as
auth_request, etc. Currently no named location was possible in any sub
requests, real (or internal) locations only.
# now you can use named location in sub requests:
# auth_request /auth_loc/;
auth_request @auth_loc;
- in addition, a second mini-commit (37d7786e7015) with new directive
"use_location" as alias or replacement for "try_files" with no file
argument and without checking the existence of file(s):
# try_files "" @loc
use_location @loc
It was allready more times discussed (goto location, etc.).
PS. If someone needs a git version of it:
https://github.com/sebres/nginx/commits/hg-sb-mod [1]
Regards,
sebres.
Links:
------
[1] https://github.com/sebres/nginx/commits/hg-sb-mod
Hi,
This is ultimately a pretty simply change. When an proxied resource has
been sdch encoded, currently the gzip module refuses to run. This change
causes gzip to run on sdch resources and ensures that gzip is appended
to the Content-Encoding header, keeping the sdch flag.
For a working sdch server implementation, see
<https://github.com/baranov1ch/connect-sdch>.
Regards,
Tom Thorogood.
Hi All,
I ran some benchmarks on our DreamFactory product running on NGINX using
Apache Benchmark
DreamFactory is a REST API platform, but from a server point of view it
should look more or less like a simple WordPress website
see the graphical results here:
www*.dreamfactory.com/publications/comparison.png
<http://dreamfactory.com/publications/comparison.png>*
the red lines show the average and maximum response time for 500 requests
at different levels of concurrency running on a "medium" aws server with 1
CPU
the blue lines show the average and maximum response time for 500 requests
at different levels of concurrency running on a "large" aws server with 2
CPUs
Does anyone know why at about 100 concurrent requests we start to see some
requests taking much longer to finish?
Is this too much work for the processor? The database is overloaded? There
is some server setting that limits concurrency?
I have also included one of the benchmark reports below, as you can see
most of the requests are handled promptly but about 5% are deferred and
take a much longer time....
Any help would be appreciated!
Thanks,
Bill Appleton
www.dreamfactory.com
Server Software: nginx
Server Hostname: next.cloud.dreamfactory.com
Server Port: 80
Document Length: 126 bytes
Concurrency Level: 200
Time taken for tests: 16.147 seconds
Complete requests: 500
Failed requests: 0
Non-2xx responses: 500
Total transferred: 298000 bytes
HTML transferred: 63000 bytes
Requests per second: 30.97 [#/sec] (mean)
Time per request: 6458.755 [ms] (mean)
Time per request: 32.294 [ms] (mean, across all concurrent requests)
Transfer rate: 18.02 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 85 209 208.7 91 725
Processing: 146 3605 2629.2 3096 15633
Waiting: 145 3604 2629.2 3095 15633
Total: 243 3814 2725.4 3189 16143
Percentage of the requests served within a certain time (ms)
50% 3189
66% 3264
75% 3831
80% 4175
90% 6766
95% 10568
98% 11114
99% 16069
100% 16143 (longest request)
I have encountered a bug in ngx_http_image_filter_module when used in conjunction with ngx_http_proxy_module ; the configuration is as following:
location /img/ {
proxy_pass http://mybucket.s3.amazonaws.com <http://mybucket.s3.amazonaws.com/>;
image_filter resize 150 100;
}
The steps to reproduce are rather complicated as they depend on how TCP fragments the response coming from the proxy:
- If http://mybucket.s3.amazonaws.com <http://mybucket.s3.amazonaws.com/> returns, in the first TCP packet, a sizable amount of data (1-2k), the image is resized correctly.
- If http://mybucket.s3.amazonaws.com <http://mybucket.s3.amazonaws.com/> returns, in the first TCP packet, a small amount of data (HTTP header, or HTTP header + a few bytes), the content is marked as not an image and NGX_HTTP_UNSUPPORTED_MEDIA_TYPE is returned (disconnecting the client), irrespective on whether or not subsequent data would complete the response to a valid image.
Nginx appears to give up right away on waiting for data if the contents of the first TCP packet received from the proxy does not contain a valid image header- i.e. ngx_http_image_test() will return NGX_HTTP_IMAGE_SIZE, etc.
In my experience this was triggered by a subtle change in AWS S3 that fragments the TCP header more.
Versions affected: 1.6.2, 1.6.3, 1.7.2, 1.8.0, etc.
Attaching a patch which fixes it for my use case (1.6.2) below; the other versions can be fixed similarly:
————————————————————————
diff -ruN nginx-1.6.2.orig/src/http/modules/ngx_http_image_filter_module.c nginx-1.6.2/src/http/modules/ngx_http_image_filter_module.c
--- nginx-1.6.2.orig/src/http/modules/ngx_http_image_filter_module.c 2014-09-16 19:23:19.000000000 +0700
+++ nginx-1.6.2/src/http/modules/ngx_http_image_filter_module.c 2015-04-28 16:25:47.000000000 +0700
@@ -317,9 +317,8 @@
}
}
- return ngx_http_filter_finalize_request(r,
- &ngx_http_image_filter_module,
- NGX_HTTP_UNSUPPORTED_MEDIA_TYPE);
+ /* wait to consume more data, do not give up on the request right away */
+ return NGX_OK;
}
/* override content type */
————————————————————————
Thoughts ? Is this the right fix ? Should I also post on the nginx Trac ?
Thank you,
Dan