# Bug? Closing upstream fastcgi requests on 0.8.15/0.7.62

**URL:** <https://www.ruby-forum.com/t/bug-closing-upstream-fastcgi-requests-on-0-8-15-0-7-62/175542>\
**Category:** NGINX\
**Created:** [September 15, 2009, 12:48pm UTC](https://www.ruby-forum.com/t/bug-closing-upstream-fastcgi-requests-on-0-8-15-0-7-62/175542 "2009-09-15T12:48:04Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jwigal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/6a8cbe/32.png) [@jwigal](https://www.ruby-forum.com/u/jwigal)\
**Post date:** [September 15, 2009, 12:48pm UTC](https://www.ruby-forum.com/t/bug-closing-upstream-fastcgi-requests-on-0-8-15-0-7-62/175542/1 "2009-09-15T12:48:04Z")

</div>

Hi all,

I’m seeing a massive spike of nginx connections in read state, which  
appears  
to be related to fastcgi upstream connections [1]. Usually I’ll have 0.6  
avg  
and ~25 max connections in read state, but with 0.8.15/0.7.62 I’ve seen  
34.0  
avg and 52.4 max… and it looks like my fastcgi upstream doesn’t like  
that  
very much. 😉

Thoughts?

Thanks,

- Jeff

[1] I reverted to proxy\_pass and the read state connections disappeared.

---

<div class="post-metadata">

**Author:** ![jwigal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/6a8cbe/32.png) [@jwigal](https://www.ruby-forum.com/u/jwigal)\
**Post date:** [September 15, 2009, 1:31pm UTC](https://www.ruby-forum.com/t/bug-closing-upstream-fastcgi-requests-on-0-8-15-0-7-62/175542/2 "2009-09-15T13:31:24Z")

</div>

On Tue, Sep 15, 2009 at 08:35:41PM +1000, Jeff W. wrote:

> Hi all,
> 
> I’m seeing a massive spike of nginx connections in read state, which appears  
> to be related to fastcgi upstream connections [1]. Usually I’ll have 0.6 avg  
> and ~25 max connections in read state, but with 0.8.15/0.7.62 I’ve seen 34.0  
> avg and 52.4 max… and it looks like my fastcgi upstream doesn’t like that  
> very much. 😉
> 
> Thoughts?

The read state is just reading request (not including body).  
This state is before any fastcgi interaction.

---

<div class="post-metadata">

**Author:** ![jwigal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/6a8cbe/32.png) [@jwigal](https://www.ruby-forum.com/u/jwigal)\
**Post date:** [September 15, 2009, 2:00pm UTC](https://www.ruby-forum.com/t/bug-closing-upstream-fastcgi-requests-on-0-8-15-0-7-62/175542/3 "2009-09-15T14:00:40Z")

</div>

> I’m seeing a massive spike of nginx connections in read state, which appears  
> to be related to fastcgi upstream connections [1]. Usually I’ll have 0.6 avg  
> and ~25 max connections in read state, but with 0.8.15/0.7.62 I’ve seen 34.0  
> avg and 52.4 max… and it looks like my fastcgi upstream doesn’t like that  
> very much. 😉

Ouch, looks like I spoke too soon – it’s happening again without  
fastcgi in  
active use. Here’s what the connections in read state chart looks like:

[http://www.gnome.org/~jdub/2009/nginx-0.7.62-connread.png](http://www.gnome.org/~jdub/2009/nginx-0.7.62-connread.png)

There _could_ be a slight lagging correlation with the active  
connections  
chart, showing spikes of connections left in the read state about a  
minute  
after similar spikes in active connections… but it’s definitely not a  
one-to-one relationship, even excluding the static files being served.

- Jeff

---

<div class="post-metadata">

**Author:** ![jwigal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/6a8cbe/32.png) [@jwigal](https://www.ruby-forum.com/u/jwigal)\
**Post date:** [September 15, 2009, 2:24pm UTC](https://www.ruby-forum.com/t/bug-closing-upstream-fastcgi-requests-on-0-8-15-0-7-62/175542/4 "2009-09-15T14:24:39Z")

</div>

On Tue, Sep 15, 2009 at 09:44:41PM +1000, Jeff W. wrote:

> [http://www.gnome.org/~jdub/2009/nginx-0.7.62-connread.png](http://www.gnome.org/~jdub/2009/nginx-0.7.62-connread.png)
> 
> There _could_ be a slight lagging correlation with the active connections  
> chart, showing spikes of connections left in the read state about a minute  
> after similar spikes in active connections… but it’s definitely not a  
> one-to-one relationship, even excluding the static files being served.

Many reading states may indicate some network issues.
