[revServer] process timeout issue

Mon Aug 2 10:51:46 EDT 2010

Michael,

Good TX joke, btw! Better than any answer I could give.

Based on Andrew's research (I believe it was a report he voluntarily did for Runrev) and our observations, the timeout is not 30 seconds for one process. 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.

I know all that sounds pretty bad, but revServer is also very fast once it gets going. VERY fast. Rodeo users are not complaining about their server speeds, Sarah and I are unhappy with the performance because we load test it and see some requests take many seconds to complete and then the next identical request takes less than a second. We can't release a commercial product with this limitation.

For the record, the testing we did was using the revServer engine 100% without revDB or anything like that. I'll let Andrew comment on that aspect of his timings.

Best,

Jerry Daniels

Follow the Rodeo discussion:
http://rodeoapps.com/discuss-among-yourselves-0

On Aug 2, 2010, at 9:08 AM, Michael Kann wrote:

> Jerry,
> 
> Does the "stuttering or hiccuping" always occur at the 30 second time limit? Or can it occur before then?
> 
> Your incredible problem solving ability brings to mind a joke that I'm sure you'll understand.
> 
> Why did the Texas chicken cross the road?
> 
> -- answer way down at the bottom--
> 
> 
> 
> --- On Mon, 8/2/10, Jerry Daniels <jerry.daniels at me.com> wrote:
> 
> From: Jerry Daniels <jerry.daniels at me.com>
> Subject: Re: [revServer] process timeout issue
> To: "How to use Revolution" <use-revolution at lists.runrev.com>
> Date: Monday, August 2, 2010, 8:22 AM
> 
> Mike,
> 
> The problem is not the number of people using Rodeo and thus going against the revServer.
> 
> The issue with revServer stuttering or hiccuping sporadically was there when we had two users, and it is still there with hundreds of users. 
> 
> Our solution to the timeout limitation is to just send the request to the server again. But we do not want to release a product that requires this.
> 
> No one is complaining about Rodeo's revServer performance, except Sarah and I. Why? Because we load and performance test our software and didn't like what we found. So we announced we are switching to PHP because of it.
> 
> RevServer may suit your tasks perfectly well. The initial building of CGIs is certainly fast. We have concerns regarding this timeout issue and are not going to wait for a fix. We factored our code for an easy transfer to PHP from the beginning, anticipating there might be issues with revServer.
> 
> Hope that helps,
> 
> Jerry Daniels
> 
> Follow the Rodeo discussion:
> http://rodeoapps.com/discuss-among-yourselves-0
> 
> 
> On Aug 2, 2010, at 8:08 AM, Michael Kann wrote:
> 
>> Andre,
>> 
>> The problem is that the Rodeo has become a Stampede.
>> 
>> Mike
>> 
>> --- On Mon, 8/2/10, Andre Garzia <andre at andregarzia.com> wrote:
>> 
>> From: Andre Garzia <andre at andregarzia.com>
>> Subject: Re: [revServer] process timeout issue
>> To: "How to use Revolution" <use-revolution at lists.runrev.com>
>> Date: Monday, August 2, 2010, 7:54 AM
>> 
>> sorry for being delusional but I believe there is no unix problem that I
>> can't solve (given time, tea and chocolates). What is happening?
>> 
>> I am not a r*d*o customer but I am a heavy revServer guy, so I can probably
>> help
>> 
>> On Mon, Aug 2, 2010 at 8:11 AM, Robert Mann <rman at free.fr> wrote:
>> 
>>> 
>>> Hi ! Our r*d*o friends that are up front in delivering a real size
>>> revServer
>>> application, seem to be head-to-front against a severe limitation of
>>> revserver. This limitation seems so severe that they seem to plan to move..
>>> to PHP! (cf. rodeo main page).
>>> 
>>> I personnaly did invest some time an money on on-rev and am planning to
>>> deploy some first real size applications using on-rev.
>>> 
>>> So this piece of news is like a bomb and I call all revServer concerned
>>> intelligence to gather and share their views, test results, etc on this
>>> particular subject as well as on the more general subject of up-scaling
>>> from
>>> play test apps with on-rev to real size projects. I'll soon post there my
>>> test results.
>>> 
>>> Please, this is NOT yet a new r$d*o discussion, this is a revServer
>>> discussion. Thanks to all for keeping it in that line!
>>> 
>>> Have a nice day though, RObert!
>>> --
>>> View this message in context:
>>> http://runtime-revolution.278305.n4.nabble.com/revServer-process-timeout-issue-tp2310168p2310168.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
>>> 
>> 
>> 
>> 
>> -- 
>> 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
> 
> _______________________________________________
> 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
> 
> Answer:
> 
> To prove to the armadillo that "IT CAN BE DONE"
> 
> Mike
> 
> 
> 
> 
> _______________________________________________
> 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