Re: [Speedycgi-users] speedy parameters
Brought to you by:
samh
|
From: Sam H. <sa...@da...> - 2002-10-17 20:33:01
|
> 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 |