Hi.
I have RoR app. It needs to use keepalive in its responses. It sits on
apache. I’ve configured apache and its serving static files from apache
with keepalive working, but dynamic pages generated by the RoR app are
closing the connection (tested thoroughly, and the response headers also
confirm this).
Any ideas?..
Cheers
Phil
On Fri, Jan 13, 2012 at 5:49 AM, Philip T. [email protected] wrote:
I have RoR app. It needs to use keepalive in its responses. It sits on
apache. I’ve configured apache and its serving static files from apache
with keepalive working, but dynamic pages generated by the RoR app are
closing the connection (tested thoroughly, and the response headers also
confirm this).
Any ideas?..
Yes, provide some actual information about your environment, like
the exact versions of Ruby, Rails, Apache, what the heck “sits on
apache” means, etc.
–
Hassan S. ------------------------ [email protected]
twitter: @hassan
Friendly in here isn’t it.
Fedora 12. Apache 2, not sure on ruby and rails versions until Monday.
Passenger (Monday for version) apache module links to RoR app.
I’m new to the project and the language, and stack in general. Apologies
if this is an annoyance, but here I am.
Thanks for your response.
On Fri, Jan 13, 2012 at 11:44 AM, Philip T. [email protected]
wrote:
Friendly in here isn’t it.
I’m new to the project and the language, and stack in general. Apologies
if this is an annoyance, but here I am.
Newness isn’t cause for annoyance, but it’s impossible for anyone to
offer reasonable help without knowing your environment. Detail matters.
Fedora 12. Apache 2, not sure on ruby and rails versions until Monday.
Passenger (Monday for version) apache module links to RoR app.
OK, is this a public URL? Or do you have a small test case that can
demonstrate the problem?
–
Hassan S. ------------------------ [email protected]
twitter: @hassan
I’ve not tried others, and there may be push back if I suggest this as a
solution, for various reasons. So solving with apache is my current
goal. It may also be worth noting that it’s https in production, and it
seems to keep connections alive for some clients but not others for
http, but closes for all on https.
I can’t give out the link in question. Sorry. However I can explain what
is happening. The connection is being closed on dynamic pages.
Refreshing the same page results in a full https handshake (2 full round
trips). Also the response headers show connection: close. But only for
dynamic content.
Static content is sending connection: Keep-Alive in the response header
and sure enough, when the page is refreshed the connection time is 0ms.
I.e. the connection has successfully been left open.
Googleing suggests that the keepAlive setting in Apache is all I need to
change. Having change the httpd.conf I can see the changes (examinin the
response headers) in the static content, but not the ruby stuff.
The output from ruby is using render to output xml.
What other details would you like to know?
On Sat, Jan 14, 2012 at 7:31 AM, Philip T. [email protected] wrote:
Googleing suggests that the keepAlive setting in Apache is all I need to
change. Having change the httpd.conf I can see the changes (examinin the
response headers) in the static content, but not the ruby stuff.
Do you see the same behavior with another web server, e.g. webrick?
I don’t use Passenger so I’m not sure if this is expected behavior, but
unicorn, for instance, explicitly does not keep connections open.
–
Hassan S. ------------------------ [email protected]
twitter: @hassan
On Sat, Jan 14, 2012 at 9:30 AM, Philip T. [email protected] wrote:
I’ve not tried others, and there may be push back if I suggest this as a
solution, for various reasons.
I didn’t suggest it as a solution; it’s part of problem isolation.
And don’t you have a development/test/staging environment which
replicates your production environment, where you can try things like
this? If not, creating one would be my very next act…
It may also be worth noting that it’s https in production, and it
seems to keep connections alive for some clients but not others for
http, but closes for all on https.
Could be helpful – with some detail.
What determines which requests go to https?
Which clients get the behavior you want, which don’t, and how do the
request headers differ?
–
Hassan S. ------------------------ [email protected]
twitter: @hassan