| Author |
Message |
< Yaws mailing list ~ Limiting execution time/number of reductions for .yaws code |
| Guest |
 Posted: Wed Jul 28, 2010 11:50 pm |
 |
|
|
Guest
|
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> configuration variables:
yawsmaxruntime and yawsmaxreductions can be used to limit the number
of seconds/reductions the execution of a single .yaws file may take.
For websocket processes, the settings wsmaxruntime and wsmaxreductions
apply.
This has currently the following limitations:
* Not tested in production
* Monitor must run on the same node as the workers (due to a
limitation in erlang:process_info)
* No proper HTTP response is sent if a worker is terminated due to
exceedance of a limit (This is somewhat impossible in streaming
mode anyway)
HC
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Jul 29, 2010 10:28 pm |
|
|
|
Guest
|
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> configuration variables:-_
Hmm, I ... think this is a pretty strange config variable, what
does the list think?
As long as the client socket is alive and want things, well - it
want things. Also - it's really really easy to program this IMHO
odd feature on the side.
/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:08 am |
|
|
|
Guest
|
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: Fri Jul 30, 2010 8:01 am |
|
|
|
Guest
|
On Thu, Jul 29, 2010 at 09:58:30PM -0400, Steve Vinoski wrote:
> 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: Sun Aug 01, 2010 11:54 pm |
|
|
|
Guest
|
On 07/30/2010 10:00 AM, Hans-Christian Esperer wrote:
>
> Speaking limits, I had planned to also try to limit the memory usage
> for each yaws script somehow.
This is no easy task - covering all cases - is hard to say the least.
/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: Wed Aug 04, 2010 5:36 pm |
|
|
|
Guest
|
On Sun, Aug 01, 2010 at 09:18:46PM -0400, Steve Vinoski wrote:
> On Sun, Aug 1, 2010 at 7:54 PM, Claes Wikstrom <klacke@tail-f.com> wrote:
> > On 07/30/2010 10:00 AM, Hans-Christian Esperer wrote:
> >
> >>
> >> Speaking limits, I had planned to also try to limit the memory usage
> >> for each yaws script somehow.
> >
> > This is no easy task - covering all cases - is hard to say the least.
You can't cover all cases - if a .yaws file calls list_to_atom() on
data receieved over the net, for example, you're doomed.
>
> Agreed. If someone really wants to explore this area, memsup and
> alarm_handler are the places to look:
>
> http://www.erlang.org/doc/man/memsup.html
> http://www.erlang.org/doc/man/alarm_handler.html
I am not sure memsup works in this case - wasn't it designed for
long-running processes to detect subtle memory leaks that manifest
over time?
HC
Post received from mailinglist |
|
|
| 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
