unsubscribe

Tony Curwen tony at secondrise.com
Thu Nov 15 00:00:35 UTC 2012


unsubscribe

On Nov 14, 2012, at 7:26 PM, nginx-request at nginx.org wrote:

> Send nginx mailing list submissions to
> 	nginx at nginx.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.nginx.org/mailman/listinfo/nginx
> or, via email, send a message with subject or body 'help' to
> 	nginx-request at nginx.org
> 
> You can reach the person managing the list at
> 	nginx-owner at nginx.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nginx digest..."
> 
> 
> Today's Topics:
> 
>   1. Can NGinx replace Varnish (gt420hp)
>   2. Re: Caucho Resin: faster than nginx? (Liu Lantao)
>   3. Chunked transfer encoding problem (Piotr Bartosiewicz)
>   4. Re: Chunked transfer encoding problem (Maxim Dounin)
>   5. Re: Can NGinx replace Varnish (Ant?nio P. P. Almeida)
>   6. Re: Can NGinx replace Varnish (Francis Daly)
>   7. proxy_cache_valid for zero seconds (shmapty)
>   8. Connection reset by peer on first request (Cancer)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 14 Nov 2012 09:31:28 -0500
> From: "gt420hp" <nginx-forum at nginx.us>
> To: nginx at nginx.org
> Subject: Can NGinx replace Varnish
> Message-ID:
> 	<9531e96577bd46912b012ef518b4c69c.NginxMailingListEnglish at forum.nginx.org>
> 	
> Content-Type: text/plain; charset=UTF-8
> 
> We are using Varnish in front of 3 load balanced web servers running apache.
> We had migrated from one hosting platform where we had 1 app server and 1
> database server using Varnish (Drupal 6.x) and had no issues.  Now that we
> are running in a load balanced environment (3 load balanced apache web
> servers, a Varnish server, and 1 database server) we are seeing mulitple
> examples of cacheing issues. (Pages not displaying correctly ...style
> issues, data input staying cached and used on another page, etc).
> 
> We think we can just replace the Varnish server and use a NGinx server.  I
> don't want to necessarily remove all the apache servers, but we have to get
> this cacheing issue corrected....
> 
> any thoughts...?
> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?2,232796,232796#msg-232796
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 14 Nov 2012 23:06:05 +0800
> From: Liu Lantao <liulantao at gmail.com>
> To: nginx at nginx.org
> Subject: Re: Caucho Resin: faster than nginx?
> Message-ID:
> 	<CAO5q5ULUN9Qpd1Q+yyzCM22EMvXKdgYrXSJCBmVt=VzN5mek=g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> We are making a nginx benchmark under 10Gbe network. For an empty page, we
> get about 700k rps of nginx, in compare with about 100k rps of resin pro.
> 
> In caucho's test, they use i7 4 core / 8 HT, 2.8 GHZ, 8Meg Cache, 8 GB RAM,
> and I use duo intel e5645. I think the result can be improved through some
> tuning.
> 
> We tuned server configuration and nginx configuration, but didn't tune much
> on resin. We didn't find any configuration of caucho's testing, neither
> nginx nor resin. so i wonder how to make the rps of resin go above 100k?
> 
> On Sat, Aug 18, 2012 at 3:26 PM, Mike Dupont <jamesmikedupont at googlemail.com
>> wrote:
> 
>> Resin Pro 4.0.29, so whats the point? We are talking about open source
>> software here, no?
>> mike
>> 
>> On Sat, Aug 18, 2012 at 6:39 AM, Adam Zell <zellster at gmail.com> wrote:
>>> More details:
>>> 
>> http://blog.caucho.com/2012/07/05/nginx-120-versus-resin-4029-performance-tests/
>>> .
>>> 
>>> On Fri, Aug 17, 2012 at 10:14 PM, Mike Dupont
>>> <jamesmikedupont at googlemail.com> wrote:
>>>> 
>>>> which version of resin did they use, the open source or pro version?
>>>> mike
>>>> 
>>>> On Fri, Aug 17, 2012 at 11:18 PM, Adam Zell <zellster at gmail.com> wrote:
>>>>> FYI:
>>>>> 
>>>>> 
>> http://www.caucho.com/resin-application-server/press/resin-java-web-server-outperforms-nginx/
>>>>> 
>>>>> " Using industry standard tool and methodology, Resin Pro web server
>> was
>>>>> put
>>>>> to the test versus Nginx, a popular web server with a reputation for
>>>>> efficiency and performance. Nginx is known to be faster and more
>>>>> reliable
>>>>> under load than the popular Apache HTTPD. Benchmark tests between
>> Resin
>>>>> and
>>>>> Nginx yielded competitive figures, with Resin leading with fewer
>> errors
>>>>> and
>>>>> faster response times. In numerous and varying tests, Resin handled
>> 20%
>>>>> to
>>>>> 25% more load while still outperforming Nginx. In particular, Resin
>> was
>>>>> able
>>>>> to sustain fast response times under extremely heavy load while Nginx
>>>>> performance degraded. "
>>>>> 
>>>>> --
>>>>> Adam
>>>>> zellster at gmail.com
>>>>> 
>>>>> _______________________________________________
>>>>> nginx mailing list
>>>>> nginx at nginx.org
>>>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>>> 
>>>> 
>>>> 
>>>> --
>>>> James Michael DuPont
>>>> Member of Free Libre Open Source Software Kosova http://flossk.org
>>>> Saving wikipedia(tm) articles from deletion
>>>> http://SpeedyDeletion.wikia.com
>>>> Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
>>>> Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
>>>> 
>>>> _______________________________________________
>>>> nginx mailing list
>>>> nginx at nginx.org
>>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Adam
>>> zellster at gmail.com
>>> 
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>> 
>> 
>> 
>> --
>> James Michael DuPont
>> Member of Free Libre Open Source Software Kosova http://flossk.org
>> Saving wikipedia(tm) articles from deletion
>> http://SpeedyDeletion.wikia.com
>> Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
>> Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
>> 
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>> 
> 
> 
> 
> -- 
> Liu Lantao
> EMAIL: liulantao ( at ) gmail ( dot ) com ;
> WEBSITE: http://www.liulantao.com/portal .
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20121114/2268cd2a/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 14 Nov 2012 17:42:49 +0100
> From: Piotr Bartosiewicz <piotr.bartosiewicz at firma.gg.pl>
> To: nginx at nginx.org
> Subject: Chunked transfer encoding problem
> Message-ID: <50A3CA09.1080709 at firma.gg.pl>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Hi,
> 
> My nginx (1.2.4) config looks like this (relevant part):
> 
> server {
>   listen 8888;
> 
>   location / {
>     proxy_http_version 1.1;
>     proxy_pass http://localhost:8080;
>   }
> }
> 
> Backend server handles GET requests and responds with a large body.
> Response is generated and sent on the fly, so content-length is not 
> known at the beginning.
> In normal case everything works fine.
> 
> But sometimes server catches an exception after a response headers were 
> sent.
> I've found that there is a commonly used solution to inform a client 
> about incomplite response:
> use Transfer-Encoding chunked and close socket without sending the last 
> (0 length) chunk.
> Unfortunately nginx appends termination chunk even when the backend 
> server does not
> (both nginx and backed connections are http/1.1 and use chunked encoding).
> 
> Is this expected behavior, bug or maybe there is some option to turn 
> this off?
> 
> Regards
> Piotr Bartosiewicz
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 14 Nov 2012 21:07:35 +0400
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx at nginx.org
> Subject: Re: Chunked transfer encoding problem
> Message-ID: <20121114170735.GZ40452 at mdounin.ru>
> Content-Type: text/plain; charset=us-ascii
> 
> Hello!
> 
> On Wed, Nov 14, 2012 at 05:42:49PM +0100, Piotr Bartosiewicz wrote:
> 
>> Hi,
>> 
>> My nginx (1.2.4) config looks like this (relevant part):
>> 
>> server {
>>  listen 8888;
>> 
>>  location / {
>>    proxy_http_version 1.1;
>>    proxy_pass http://localhost:8080;
>>  }
>> }
>> 
>> Backend server handles GET requests and responds with a large body.
>> Response is generated and sent on the fly, so content-length is not
>> known at the beginning.
>> In normal case everything works fine.
>> 
>> But sometimes server catches an exception after a response headers
>> were sent.
>> I've found that there is a commonly used solution to inform a client
>> about incomplite response:
>> use Transfer-Encoding chunked and close socket without sending the
>> last (0 length) chunk.
>> Unfortunately nginx appends termination chunk even when the backend
>> server does not
>> (both nginx and backed connections are http/1.1 and use chunked encoding).
>> 
>> Is this expected behavior, bug or maybe there is some option to turn
>> this off?
> 
> This is sort of known bug.  Fixing it would require relatively 
> large cleanup of upstream module.
> 
> -- 
> Maxim Dounin
> http://nginx.com/support.html
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 14 Nov 2012 18:39:41 +0100
> From: Ant?nio P. P. Almeida <appa at perusio.net>
> To: nginx at nginx.org
> Subject: Re: Can NGinx replace Varnish
> Message-ID: <87bof0f5ia.wl%appa at perusio.net>
> Content-Type: text/plain; charset=US-ASCII
> 
> On 14 Nov 2012 15h31 CET, nginx-forum at nginx.us wrote:
> 
>> We are using Varnish in front of 3 load balanced web servers running
>> apache.  We had migrated from one hosting platform where we had 1
>> app server and 1 database server using Varnish (Drupal 6.x) and had
>> no issues.  Now that we are running in a load balanced environment
>> (3 load balanced apache web servers, a Varnish server, and 1
>> database server) we are seeing mulitple examples of cacheing
>> issues. (Pages not displaying correctly ...style issues, data input
>> staying cached and used on another page, etc).
> 
> You can drop Varnish from the picture if something like microcaching
> suits you or you use ngx_cache_purge with the purge module. It depends
> if you have an active invalidation strategy or not. Either way Nginx
> can replace Varnish and work also as load balancer. So you'll have a
> simpler stack.
> 
>> We think we can just replace the Varnish server and use a NGinx
>> server.  I don't want to necessarily remove all the apache servers,
>> but we have to get this cacheing issue corrected....
>> 
>> any thoughts...?
> 
> Yep. See above. For Drupal related Nginx issues there's a GDO group:
> 
> http://groups.drupal.org/nginx
> 
> if want to delve deeper into the issue.
> 
> --- appa
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 14 Nov 2012 18:32:53 +0000
> From: Francis Daly <francis at daoine.org>
> To: nginx at nginx.org
> Subject: Re: Can NGinx replace Varnish
> Message-ID: <20121114183253.GI24351 at craic.sysops.org>
> Content-Type: text/plain; charset=us-ascii
> 
> On Wed, Nov 14, 2012 at 09:31:28AM -0500, gt420hp wrote:
> 
> Hi there,
> 
>> we are seeing mulitple
>> examples of cacheing issues. (Pages not displaying correctly ...style
>> issues, data input staying cached and used on another page, etc).
>> 
>> We think we can just replace the Varnish server and use a NGinx server.  I
>> don't want to necessarily remove all the apache servers, but we have to get
>> this cacheing issue corrected....
> 
> If the caching issues are because your backend servers are configured
> incorrectly, merely replacing Varnish with nginx is unlikely to fix
> everything.
> 
> If they are because your Varnish is configured incorrectly, then
> replacing an incorrectly-configured Varnish with a correctly-configured
> nginx probably will help. But replacing it with a correctly-configured
> Varnish would probably also help.
> 
> Good luck with it,
> 
> 	f
> -- 
> Francis Daly        francis at daoine.org
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed, 14 Nov 2012 16:09:44 -0500
> From: "shmapty" <nginx-forum at nginx.us>
> To: nginx at nginx.org
> Subject: proxy_cache_valid for zero seconds
> Message-ID:
> 	<f96c9d4c0fb2a6721186694a5c42c5f4.NginxMailingListEnglish at forum.nginx.org>
> 	
> Content-Type: text/plain; charset=UTF-8
> 
> Greetings,
> 
> I am trying to configure nginx proxy_cache so that it stores a cached copy
> of a HTTP response, but serves from cache *only* under the conditions
> defined by proxy_cache_use_stale.
> 
> I have tried something like this without success:
> 
>    proxy_cache_valid           200 204 301 302 0s;
>    proxy_cache_use_stale       error timeout updating invalid_header
> http_500 http_502 http_504;
> 
> "0s" appears to avoid caching completely.  "1s" stores a cached copy, but
> presumably serves from cache for one second.  I am trying to serve from
> cache only when the upstream errs.
> 
> Thank you
> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?2,232815,232815#msg-232815
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Wed, 14 Nov 2012 18:26:55 -0500
> From: "Cancer" <nginx-forum at nginx.us>
> To: nginx at nginx.org
> Subject: Connection reset by peer on first request
> Message-ID:
> 	<f10a884927959154a88372ff01c2598f.NginxMailingListEnglish at forum.nginx.org>
> 	
> Content-Type: text/plain; charset=UTF-8
> 
> Hi,
> 
> I'm using Nginx with php-cgi.  A problem arose recently where if you have
> not used my site for a few minutes and then go to it, the first request is
> always 'connection reset by peer'.  If you refresh, everything functions
> normally until you leave for a few minutes and go to another link.  It
> happens 100% of the time. Does anyone know what could be the problem?
> 
> All I get in error log with debug on are these messages:
> 2012/11/14 17:25:46 [info] 3454#0: *2516 client prematurely closed
> connection while reading client request line, client: *, server: domain.com
> 
> Also, these coincide with the 400 bad request errors in access.log.  I have
> tried restart dns server, nginx, php-cgi, etc, but to no avail.
> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?2,232817,232817#msg-232817
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
> 
> End of nginx Digest, Vol 37, Issue 28
> *************************************

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20121114/9605fb71/attachment.bin>


More information about the nginx mailing list