|
|
| Author |
Message |
< Yaws mailing list ~ Limiting execution time/number of reductions for .yaws code |
| Guest |
 Posted: Mon Jul 26, 2010 5:13 pm |
 |
|
|
Guest
|
Hello,
I recently screwed up in a .yaws script which led to a runaway "loop"
under certain conditions. I got more and more worker processes that
consumed all available CPU time. Yaws got slower and slower until I
finally noticed what was wrong.
IMHO it'd be nice if one could limit the number of reductions and/or
maximum time a request is allowed to take per <server>. This could be
easily done by using a monitor process that regularily checks all
worker processes and kills rogue ones if necessary. This would work so
long as worker processes do not spawn more processes. It would also
work for websocket processes, since their PIDs are passed back to yaws
when created.
What do you think?
HC
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Jul 29, 2010 10:44 pm |
|
|
|
Guest
|
On Thu, Jul 29, 2010 at 6:27 PM, Claes Wikstrom <klacke@tail-f.com> wrote:
> On 07/29/2010 01:12 AM, Hans-Christian Esperer wrote:
>> On Mon, Jul 26, 2010 at 07:12:46PM +0200, Hans-Christian Esperer wrote:
>>> IMHO it'd be nice if one could limit the number of reductions and/or
>>> maximum time a request is allowed to take per<server>. This could be
>>> easily done by using a monitor process that regularily checks all
>>> worker processes and kills rogue ones if necessary. This would work so
>>> long as worker processes do not spawn more processes. It would also
>>> work for websocket processes, since their PIDs are passed back to yaws
>>> when created.
>>
>> Ok - here is my attempt to do it. The behaviour is controlled by four
>> per-<server> |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Jul 29, 2010 10:47 pm |
|
|
|
Guest
|
On 07/30/2010 12:43 AM, Steve Vinoski wrote:
>
> Agreed. This seems like a fairly specialized feature that doesn't
> really need to be inside Yaws itself.
>
> --steve
Settled then - patch rejected
/klacke
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/erlyaws-list
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Jul 30, 2010 1:58 am |
|
|
|
Guest
|
On Thu, Jul 29, 2010 at 9:07 PM, Hans-Christian Esperer
<hc@hcesperer.org> wrote:
> On Thu, Jul 29, 2010 at 06:43:31PM -0400, Steve Vinoski wrote:
>> On Thu, Jul 29, 2010 at 6:27 PM, Claes Wikstrom <klacke@tail-f.com> wrote:
>> > On 07/29/2010 01:12 AM, Hans-Christian Esperer wrote:
>> >> On Mon, Jul 26, 2010 at 07:12:46PM +0200, Hans-Christian Esperer wrote:
>> >>> IMHO it'd be nice if one could limit the number of reductions and/or
>> >>> maximum time a request is allowed to take per<server>. This could be
>> >>> easily done by using a monitor process that regularily checks all
>> >>> worker processes and kills rogue ones if necessary. This would work so
>> >>> long as worker processes do not spawn more processes. It would also
>> >>> work for websocket processes, since their PIDs are passed back to yaws
>> >>> when created.
>> >>
>> >> Ok - here is my attempt to do it. The behaviour is controlled by four
>> >> per-<server> |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Aug 02, 2010 1:19 am |
|
|
|
Guest
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
