This really only affects SSL connections, where if the buffer with
chunk terminator is copied into the SSL buffer by itself. Since the
new SSL buffer has not reached 16k, it's not flushed thus causing a
delay in the client seeing it.
flush_chunk_terminator.patch
Description: Binary data
_
ndrew Alexeev wrote:
> On Jul 25, 2013, at 2:49 AM, John Watson wrote:
>
> Upgraded from 1.2.9 to 1.4.1 and now started getting:
>
> [emerg] could not build the variables_hash, you should increase either
> variables_hash_max_size: 512 or variables_hash_bucket_size: 64
>
>
Upgraded from 1.2.9 to 1.4.1 and now started getting:
[emerg] could not build the variables_hash, you should increase either
variables_hash_max_size: 512 or variables_hash_bucket_size: 64
Same configuration and even dropped (2) 3rd party modules.
nginx.conf and ./configure params:
https://gist
Hi,
Trying adding this directive to your location:
echo_read_request_body;
It needs this 3rd party module though:
http://wiki.nginx.org/HttpEchoModule#echo_read_request_body
On Sun, Jul 14, 2013 at 7:23 AM, shawnxzhou wrote:
> I'm trying to use $request_body but get '-' in my log file for t
I noticed there was a patch submitted couple years ago that was never
accepted and last year a post saying to expect it around Jan 2013. I
understand SPDY probably pushed the roadmap back a bit. So I was wondering
if there is a new estimate for when to expect this 1.3.x roadmap item to be
completed
, Mar 21, 2013 at 12:29 PM, Ruslan Ermilov wrote:
> On Thu, Mar 21, 2013 at 12:03:59PM -0700, John Watson wrote:
> >Well doesn't make sense when theres >4 concurrent requests
> >At any given time there's around 12 active_connections, but sock-3 is
> >st
Well doesn't make sense when theres >4 concurrent requests
At any given time there's around 12 active_connections, but sock-3 is still
never being used
On Thu, Mar 21, 2013 at 9:34 AM, John Watson wrote:
> O... that makes complete sense now.
>
> Had 4 workers.
&g
O... that makes complete sense now.
Had 4 workers.
Thanks!
On Thu, Mar 21, 2013 at 4:47 AM, Ruslan Ermilov wrote:
> On Thu, Mar 21, 2013 at 01:45:14AM -0700, John Watson wrote:
> >Was investigating some issues today when we noticed that least_conn
> wasn't
> >
Was investigating some issues today when we noticed that least_conn wasn't
behaving as expected.
upstream backend {
least_conn;
server unix:/tmp/sock-1.sock;
server unix:/tmp/sock-2.sock;
server unix:/tmp/sock-3.sock;
}
The expected behavior for 4 simultaneous requests it should distribut
