Re: [Speedycgi-users] speedy parameters

[Sam H. <sa...@da...>]

 > I was wandering if there is a good rule of thumb to use
 > when running our scripts via speedy in regards to timeout and
 > number of times ran.

 The MaxRuns setting is mainly for resource (usually memory) leaks.
 The more leaky your program, the smaller the number should be, otherwise
 you won't reclaim those resources.  If your program doesn't leak at all,
 then you could safely unlimit it.  The downside to a small Maxruns value
 is more time is spent starting new perl interpreters rather than using
 ones already running.

 BTW, starting in 2.20, the cost of using a small Maxruns value decreased,
 especially if a lot of your overhead involves the static compilation
 of code.  The statically compiled code is now shared.  A re-spawn (after
 the maxruns limit is reached) no longer involves a re-compile of that code.

 The timeout is there to reclaim resources when a perl script is no
 longer being used.  Setting the timeout low, frees memory (and any
 other resources that script is using - like database handles) sooner,
 when your script is no longer needed.  The downside of a low timeout
 is that, on average, the time spent starting new perl interpreters
 increases.

 A good timeout value can be based on how often you think the script
 will be used.  If you have a script that's used only once an hour, you
 wouldn't want to set the timout to 30 minutes, because the script would
 just timeout, exit and then get re-spwaned every hour.  There wouldn't
 be any persistence at all.  So, maybe a good rule of thumb would be to
 choose a timeout value that is double the average rate at which the
 script is usually used (ie if the average is once per houur, choose
 a two hour timeout - something like that).

 Also, if you have plenty of memory, you can afford to keep your timeouts
 high.  If you're short on memory, start lowering your timeouts, so you free
 up memory as soon as possible.  It's a time/space tradeoff - it's the
 time cost of starting a new interpreter versus the space cost of keeping
 an interpreter around in memory.

 Sam