[RevServer tips] Spreading the load or why wise developers use asynchronous workflows

wayne durden wdurden at gmail.com
Wed Aug 4 13:17:03 EDT 2010


Thanks Andre,  I am coming to that conclusion I believe as well.  Wrestling
with how to do some processing and save state of where it is and restart at
the left off point...

What still doesn't quite make sense to me is why if the server is already
slicing its resources amount users (I get x memory and x amount of the
processing time on the server), exactly why there then needs to be any per
process limitation time wise if the OS can already swap resources between
users.  This isn't a question I need answered, it's just a matter of wanting
to understand more concretely "all the way down" exactly how things work.  I
accept that it is so, and I suspect that the granularity of the OS time
slice parceling amongst users perhaps isn't nearly as easy if a user has a
process continually running.

Please don't spend any more time responding, I will do some side reading to
satisfy the curiosity until I reach my limit of effort to curiosity.  Thanks
again for all you put out on this list!  Great pointers for how I have to
rethink my app to turn it into a server service.

Wayne

On Wed, Aug 4, 2010 at 1:02 PM, Andre Garzia <andre at andregarzia.com> wrote:

> Glad the article is useful!
>
> The OS will be able to attend you and others with no problem but it will
> enforce the limitations, meaning in about 30 secs of work, your process
> will
> shutdown. For your intensive task, the best idea is an asynchronous
> workflow
> with some kind of map/reduce or queue processing governated by the client
> browser.
>
> Andre
>
> On Wed, Aug 4, 2010 at 1:59 PM, wayne durden <wdurden at gmail.com> wrote:
>
> > Thanks Andre, and I am working through your article now as well.  I get
> > that
> > it is per process but the part that isn't still clear to me is that the
> OS
> > can be doing my intensive process for 30 seconds before closing it and
> also
> > attending to another user simultaneously or not.  I am under the
> impression
> > there is still some resource slicing going on, I just don't have a
> concrete
> > understanding...
> >
> > This is all very interesting to me because I am interested in moving a
> > desktop app that processes datafiles up to 100,000 lines which can mean
> for
> > each line comparing against the remainder (in reality sorts cust this
> down
> > a
> > great deal), but this can run for minutes on a desktop app and I have got
> > to
> > cut it down into asynchronous processing as per your article...
> >
> > Thanks!
> >
> > Wayne
> >
> > On Wed, Aug 4, 2010 at 12:54 PM, Andre Garzia <andre at andregarzia.com>
> > wrote:
> >
> > > Wayne,
> > >
> > > you got it wrong, it is a per process limitation. The policies change
> > from
> > > shared hosting company to shared hosting company. At On-Rev means that
> a
> > > single process can only use 30 secs of processing time, this is done
> > > precisely to prevent a rogue process from using all the resources and
> > thus
> > > making the life of other users a mess. No one can hog the whole server
> > for
> > > 30 seconds because, there is a CPU limit as well. It is not just time,
> > the
> > > limits are set so all users can reach the limit without affecting each
> > > other. Thats the idea
> > >
> > > Andre
> > >
> > > On Wed, Aug 4, 2010 at 1:49 PM, wayne durden <wdurden at gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > Just want to make sure I have the general understanding of the
> > issues...
> > > >  On
> > > > a shared hosting setup where there is a process time limit such as 30
> > > > seconds, would that mean that some other entity using the same server
> > > with
> > > > an intensive process could latch essentially all of the processing
> for
> > up
> > > > to
> > > > 30 seconds?  Is there a more finely granulated check that still swaps
> > > users
> > > > in and out to a degree below a certain process priority claim?  And
> if
> > > the
> > > > first assertion is the case, it wouldn't matter what tech one went
> with
> > > > Rev,
> > > > Ruby, PHP, etc. you could still get a wait time of almost 30 seconds
> > > before
> > > > the server ended your sharer's processing and reached you, correct?
> > > >
> > > > Thanks,
> > > >
> > > > Wayne
> > > > _______________________________________________
> > > > use-revolution mailing list
> > > > use-revolution at lists.runrev.com
> > > > Please visit this url to subscribe, unsubscribe and manage your
> > > > subscription preferences:
> > > > http://lists.runrev.com/mailman/listinfo/use-revolution
> > > >
> > >
> > >
> > >
> > > --
> > > http://www.andregarzia.com All We Do Is Code.
> > > _______________________________________________
> > > use-revolution mailing list
> > > use-revolution at lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-revolution
> > >
> > _______________________________________________
> > use-revolution mailing list
> > use-revolution at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-revolution
> >
>
>
>
> --
> http://www.andregarzia.com All We Do Is Code.
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



More information about the Use-livecode mailing list