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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution