[revServer] process timeout issue

[Robert Mann]

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.