[revServer] process timeout issue

[Jerry Daniels]

Robert this is a lo-o-o-o-ong post.

On Aug 2, 2010, at 8:16 PM, Robert Mann wrote:

> 
> Please let us not fall into the "bloody" trap of personnal feelings, whatever
> mood swing is expressed here or there. This list is a fantastic oportunity
> to collaborate from all over the world, for us, for our interest, not
> against anybody's interest !! ok?
> 
> The issue between Kevin and Jerry could well be that runrev would have
> benefited from Rodeo potentially if it had decided (as was once upon a time
> announced) to distribute revServer for free (the original "pitch" was :
> we'll make revServer available for free but offer the on-rev service and let
> you developpers sell protected stacks, this is what I understood and
> bought!).
> 
> If that road had been followed, rodeo, if successful, could have given a
> hand to runrev and propagate revServer with the rodeo sites that can be
> exported from the rodeo environnment... But at the price of revServer, that
> is not possible anymore, so that rodeo has to go to PHP, anyways. Full stop.
> 
> It may well be that his opening of rodeo was triggered by the revServer
> limitations that rodeo experienced (and boy I won't beleive they invented
> that...) which led them to consider moving to PHP and thus allowing to
> export more widely rodeo apps.. etc... 
> 
> What I have understood of Jerry's path these last years is that he protyped
> using runrev, tried it hard, but then was carried to develop more solid
> tools outside runrev like tRev, rodeo app, and now rodeo-php. He
> communicates and shares his experiences, so we here about it. And it is
> disturbing to all of us who "beleive(d)" in revTalk... 
> 
> So the issue we're concerned with revServer is : is it yet another
> prototyping tool only or is it a solid work horse server? Let's find out!
> 
> A) Is there a problem?
> 
> ++> There is a problem 
> Rodeo team (poor load and performance test of rodeo apps)
> Bob Sneidar (experienced unexplained time lags)
> Pierre Saohres (i can see this happen with the early requests to
> woooooooords.com : The first request can, time to time, take around 20 secs.
> After this first request, the next ones are always back to the user in less
> than some ticks.)
> Kevin Miller (do not communicate their test benches, so performance problem
> is plausible)
> Andre Garzia (You can also notice that there were requests that took 15 secs
> and others that took 3 secs, which is odd since they were all hitting the
> same page. What we can infer from this simple thing is that there are places
> that RevServer needs working but it also means we need more focus to find
> where and why it breaks)
> 
> --> There does ot seem to be a problem
> Pierre Sahores (limitations set in revServer ar standard)
> Kevin Miller (we do not have enough feedback)
> 
> 
> 
> B) What are the possible causes of the problem?
> 
> Rodeo team (We think there is some sort of pooling of processes (and
> possibly users) that are limited by 30 secs. We have seen the timeout in
> much shorter time spans. Andrew reports a 4 second time out. 
> 
> Pierre Sahores (setting 30 sec limits and 64 mb limit is standard practice,
> Could be a problem related to the RAM virtualisation of the RHEL5 host it
> self, httpd.conf, etc... )
> 
> C) consequently what precautions have revServer developpers to take
> -- do we have to re-send post or get if no answer after a while? any
> suggested routine to do so? (thank you runrev team to help too!)
> 
> D) consequently what is revServer ok for and what it is not ok for.
> -- do we have to postpone any serious launch of revServer, on-rev services
> until the beta test ends and a version one is officially launched? 
> 
> 
> -- 
> View this message in context: http://runtime-revolution.278305.n4.nabble.com/revServer-process-timeout-issue-tp2310168p2311192.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
> _______________________________________________
> 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