librelist archives

Re: [mongrel2] Timeout Capability Needs Testing

From:

Matt Towers

Date:

2011-05-09 @ 00:02

I've not been able to isolate it completely yet, but it seems that if you 
attempt to curl a route that is not defined, m2 will wait to timeout 
instead of returning a 404 immediately as before.

✈ Matt



On May 5, 2011, at 12:36 , Zed A. Shaw wrote:

> I got the timeouts working fairly well and need people to try them out.
> Here's the details on it:
> 
> There's now some new settings:
> 
> * limits.tick_timer -- How often to run the timeout/ticker which keeps
> the internal clock going.  Mongrel2 just keeps a global of the time to
> avoid calling time() repeatedly, so this setting will adjust your
> granularity.  It defaults to 10 which seems to be good enough for
> tracing stats and timeouts.
> 
> * limits.min_ping -- This is the minimum time between activity on a
> socket.  It's determined by how frequently that socket goes through the
> state machine, so it's pretty accurate for finding dead sockets.  If you
> set this to 0 then it won't be checked, and it defaults to 120 seconds.
> 
> * limits.min_read_rate -- This is the min bytes read per second from
> the socket before it's killed.  It defaults to 300.  Setting it to 0
> will disable this check.
> 
> * limits.min_write_rate -- This is the min bytes written per second to
> the socket before it's killed.  It deafults to 300 and setting it to 0
> will disable it.
> 
> * limits.kill_limit -- Works to set how many of the min_ping,
> min_read_rate, or min_write_rate must trigger before the socket is
> killed.  It defaults to 2 which means, if 2 of the 3 are true then the
> socket is killed.  Setting it to 1 is aggressive and probably not going
> to work unless you have a setup that's high traffic.  Setting it to 3
> will mean that all three have to trigger before it's killed.
> 
> Finally, these configs are read from the settings every time through the
> check, so you should be able to change them then reload and it'll adapt
> to the new values without a restart.
> 
> Alright those are the settings, so then you'd set them in the config
> with:
> 
> settings = {"min_ping": 60,
>    "min_read_rate": 100, "min_write_rate": 1000,
>    "kill_limit": 3}
> 
> Which should set this to be:
> 
> 1. Whenever all three of min_ping, min_write_rate, and min_read_rate are
> true.
> 2. With a 60 second ping timeout, read_rate of 100 bytes per second, and
> 1000 bytes write_rate.
> 3. Close the socket for taking too long.
> 
> 
> Play with this and give me feedback on how it works in practice, and
> what modifications it might need.  I'll also be adding some control port
> commands to do temporary disabling.
> 
> 
> -- 
> Zed A. Shaw
> http://zedshaw.com/

On Sun, May 08, 2011 at 05:02:56PM -0700, Matt Towers wrote:
> I've not been able to isolate it completely yet, but it seems that if
> you attempt to curl a route that is not defined, m2 will wait to
> timeout instead of returning a 404 immediately as before.

Hmm, seems to be working on my servers:

http://zedshaw.com/adsfasfdasdfasfdadsf

Can you get me a specific route that fails so I can try it?

-- 
Zed A. Shaw
http://zedshaw.com/

Try this config file.  It reproduces the error for me.

This config is one that is generated by my code, so I'm assuming there's 
something I'm doing wrong.  However, m2 loads the config file just fine, 
without complaints.  But when I attempt to curl the root, it hangs until 
the timeout expires.

I tried the same test with the most recent examples/conf/sample.conf file 
and it worked as expected.

Could it be that I don't have a default handler defined?

✈ Matt



On May 8, 2011, at 17:07 , Zed A. Shaw wrote:

> On Sun, May 08, 2011 at 05:02:56PM -0700, Matt Towers wrote:
>> I've not been able to isolate it completely yet, but it seems that if
>> you attempt to curl a route that is not defined, m2 will wait to
>> timeout instead of returning a 404 immediately as before.
> 
> Hmm, seems to be working on my servers:
> 
> http://zedshaw.com/adsfasfdasdfasfdadsf
> 
> Can you get me a specific route that fails so I can try it?
> 
> -- 
> Zed A. Shaw
> http://zedshaw.com/

The one I was testing was calling the root with no default route defined:

http://localhost:6767, though I was able to repro with any undefined 
route.  I'll poke on it today and see if I can narrow down the scenario.

Should the 404 be returning immediately or not until after the timeout?

✈ Matt



On May 8, 2011, at 17:07 , Zed A. Shaw wrote:

> On Sun, May 08, 2011 at 05:02:56PM -0700, Matt Towers wrote:
>> I've not been able to isolate it completely yet, but it seems that if
>> you attempt to curl a route that is not defined, m2 will wait to
>> timeout instead of returning a 404 immediately as before.
> 
> Hmm, seems to be working on my servers:
> 
> http://zedshaw.com/adsfasfdasdfasfdadsf
> 
> Can you get me a specific route that fails so I can try it?
> 
> -- 
> Zed A. Shaw
> http://zedshaw.com/