I am using version 7.65 on Ubuntu 10 as a reverse proxy. The backend
server is running asp pages on iis6. I have the following in my nginx
conf file -
gzip on;
gzip_disable “MSIE [1-6].”;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_comp_level 8;
gzip_min_length 0;
gzip_vary on;
gzip_proxied any;
gzip_types text/plain text/css text/xml text/javascript
application/xml application/x-javascript;
When this is on I get the content-encoding gzip header and
transfer-encoding chunked. I do not get a content-length header. When
I check compression by going to a couple of websites that confirm
compression they tell me the page is not compressed.
If i turn off the gzip I do not see the gzip and chunked headers but do
see content-length.
What do I need to change to get gzip compressing the pages? The content
type of the pages is text/html in almost every case.
Posted at Nginx Forum:
Also, compression is not enabled on the backend iis6 server. I have
tried with and without compression on the backend server and it did not
make any difference.
Posted at Nginx Forum:
We have much the same setup (nginx → IIS6) and compression works
fine. However, you have quite a few items in your gzip config that are
probably unnecessary, and might be causing issues.
I would first use a tool like Fiddler (www.fiddler2.com) rather than a
3rd party site for testing. You can see if a response is compressed
using the inspector section on the right side of the fidder window.
Secondly, try commenting out all your gzip-related settings except
“gzip on” and make sure it works with that.
Third, you likely don’t want “gzip_comp_level 8”, as it burns a lot of
CPU for saving maybe 5-10% size over the default setting (which is
gzip_comp_level 1).
Finally, add back your additional gzip-related settings until you
start to see uncompressed responses.
–
RPM
Hello!
On Tue, May 25, 2010 at 07:31:32PM -0400, reference123 wrote:
gzip_vary on;
gzip_proxied any;
gzip_types text/plain text/css text/xml text/javascript application/xml application/x-javascript;
When this is on I get the content-encoding gzip header and
transfer-encoding chunked. I do not get a content-length
header. When I check compression by going to a couple of
websites that confirm compression they tell me the page is not
compressed.
So you see it’s correctly compressed, but some external website
checkers report it’s not. Most likely it’s caused by using
HTTP/1.0 checks on these checkers. You may try to set
gzip_http_version 1.0;
to make these checkers happy. But I would recommend to keep the
default (gzip_http_version 1.1) instead to avoid problems with
real HTTP/1.0 clients/proxies.
Maxim D.
On Wed, May 26, 2010 at 5:03 PM, reference123 [email protected]
wrote:
Ryan, we use such high compression because we are running on a machine with
a lot of cpu overhead. If the higher compression starts to put some
pressure on the CPU we will lower it and I appreciate the reminder about
that.
Right, but it will stil affect latency 
Thanks for the help. Got it working this morning. I did as Ryan
suggested and found it was related to the gzip disable statement. I
added MSIE [1-6].(?!.*SV1) the () part to that statement and it works.
Ryan, we use such high compression because we are running on a machine
with a lot of cpu overhead. If the higher compression starts to put
some pressure on the CPU we will lower it and I appreciate the reminder
about that.
Do you do any type of caching with the proxy and if so, have you had any
issues? We would like to cache our dynamic asp pages but have been
cautious because of viewstate and sessions.
Finally, do you use more than one backend server and if so have you
found a good resolution to the Etag issue. I have tried many of the IIS6
options I found online with no result. I am getting tempted to block
the Etag header at the proxy level at this point.
Thanks,
Craig
Posted at Nginx Forum:
On Wed, May 26, 2010 at 10:03 AM, reference123 [email protected]
wrote:
Do you do any type of caching with the proxy and if so, have you had
any issues? Â We would like to cache our dynamic asp pages but have
been cautious because of viewstate and sessions.
We only cache static items with nginx at the moment (images and
JS/CSS). Viewstate and sessions can be incompatible with any form of
caching on a public proxy. Caching a dynamic page only helps if the
same exact page can be safely delivered to multiple users (such as
Wikipedia’s pages). You could conceivably add in the session cookie as
part of proxy_cache_key, but that is rather pointless since you can
have the user’s own browser cache the page with simple “Cache-Control:
private,max-age=600” set by the ASP.net code (or even by nginx). If it
is a custom per-user response anyway, no reason to cache it on your
proxy, cache it in the browser.
Finally, do you use more than one backend server and if so have you
found a good resolution to the Etag issue. I have tried many of the IIS6
options I found online with no result. Â I am getting tempted to block the
Etag header at the proxy level at this point.
We have synchronized the E-tag seeds to 0 on all of our IIS boxes
(there’s an MS knowledge-base article about it). Works like a champ,
but you also have to make sure all of the files have the same last
modified date-stamps on all of your back-ends (ROBOCOPY can do this,
or rsync). You can of course simply also block the Etag header at the
proxy. We didn’t do that because we have some Tomcat applications that
set the Etag header dynamically. Apache has similar issues with E-Tags
in its default configuration (they use filesystem inode numbers).
–
RPM
Ryan,
Thanks again for the quick response. One last question, have you tried
to sync your web farm servers at all with the Microsoft Web Deploy tool
and if so, did it work well or not? We have been collecting information
on it but are cautious to implement without more info.
Craig
Posted at Nginx Forum:
Luca,
Thank you. I will watch the latency as well. It is running on a AMD
x64 Dual core with 4 gig of ram and only acting as a reverse proxy at
the moment (no caching and only 2 simple rewrites). It does have over a
million pages a month run through it though. We do want to find the
best balance between all the considerations.
Posted at Nginx Forum:
On Wed, May 26, 2010 at 11:10 AM, reference123 [email protected]
wrote:
Thanks again for the quick response. Â One last question, have you tried to sync
your web farm servers at all with the Microsoft Web Deploy tool and if so, did it
work well or not? Â We have been collecting information on it but are cautious to
implement without more info.
Nope, we sync IIS metabase settings by hand using WinMerge and content
using ROBOCOPY. Our IIS configuration is simple enough and static
enough to make that feasible. When developers ask for IIS settings
changes, we ususally point out better ways to handle the issue in
their code or config files that makes things easier for everybody.
–
RPM