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

Andre Garzia andre at andregarzia.com
Wed Aug 4 12:02:36 CDT 2010


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.



More information about the use-livecode mailing list