=)
That module passed all our tests, both in dev and staging environments. We
were deploying in batches and got it on the first one. We also rolled back
before any incidents.
Not perfect but pretty safe, I think.
Maybe we need to be more 'creative' with our testing.
On Tue, Jan 19, 2016 at 6:47
Testingin production?
Well you are not the only one... far from that.
There are other means to create 'realistic' traffic on benches, provided
you are thinking those tests well, though.
---
*B. R.*
On Mon, Jan 18, 2016 at 7:33 PM, Marcelo MD wrote:
> Hi,
>
> Just getting back to you. Sorry abou
Hi,
Just getting back to you. Sorry about the delay.
This behaviour was caused by a custom patch in a module. The patch was
ending the requests without finalizing them, leaking connections.
Eventually Nginx just exploded =) Nothing like production workload to
stress things out.
Thanks a lot.
On Friday 18 December 2015 15:55:47 Marcelo MD wrote:
> Hi,
>
> Recently we added a 'thread_pool' directive to our main configuration. A
> few hours later we saw a huge increase in the connections_writing stat as
> reported by stub_status module. This number reached +- 3800 and is stuck
> there si
>From what you provided, I do not see anything unexpected...
Enabling threads usage with thread_pool and aio threads enables
asynchronous file reading/writing.
The connections_writing stat indicates... the number of connections to
which the server is writing a response.
Since you are working asyn
Hi,
Recently we added a 'thread_pool' directive to our main configuration. A
few hours later we saw a huge increase in the connections_writing stat as
reported by stub_status module. This number reached +- 3800 and is stuck
there since. The server in question is operating normally, but this is ver
