[revServer] process timeout issue

classic Classic list List threaded Threaded
88 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

[revServer] process timeout issue

Robert Mann
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!
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Andre Garzia-3
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Michael Kann
Andre,

The problem is that the Rodeo has become a Stampede.

Mike

--- On Mon, 8/2/10, Andre Garzia <[hidden email]> wrote:

From: Andre Garzia <[hidden email]>
Subject: Re: [revServer] process timeout issue
To: "How to use Revolution" <[hidden email]>
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution



     
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Jerry Daniels-2
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 <[hidden email]> wrote:
>
> From: Andre Garzia <[hidden email]>
> Subject: Re: [revServer] process timeout issue
> To: "How to use Revolution" <[hidden email]>
> 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 <[hidden email]> 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
>> [hidden email]
>> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
>
>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Andre Garzia-3
Jerry,

If you think it still worth it, contact me privately, we can try to pinpoint
where the hiccup happens, maybe it is not the core engine but some external
such as revdb. I've never seen revServer hiccup but I am not under intense
fire such as rodeo server.

Cheers and keep up the good work!

Andre

On Mon, Aug 2, 2010 at 10:22 AM, Jerry Daniels <[hidden email]> wrote:

> 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 <[hidden email]> wrote:
> >
> > From: Andre Garzia <[hidden email]>
> > Subject: Re: [revServer] process timeout issue
> > To: "How to use Revolution" <[hidden email]>
> > 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 <[hidden email]> 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
> >> [hidden email]
> >> 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
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-revolution
> >
> >
> >
> >
> > _______________________________________________
> > use-revolution mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Michael Kann
In reply to this post by Jerry Daniels-2
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 <[hidden email]> wrote:

From: Jerry Daniels <[hidden email]>
Subject: Re: [revServer] process timeout issue
To: "How to use Revolution" <[hidden email]>
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 <[hidden email]> wrote:
>
> From: Andre Garzia <[hidden email]>
> Subject: Re: [revServer] process timeout issue
> To: "How to use Revolution" <[hidden email]>
> 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 <[hidden email]> 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
>> [hidden email]
>> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
>
>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Richard Gaskin
In reply to this post by Robert Mann
I agree there should be no such limit in any server-side engine, and
would be willing to bet this was put into RevServer to protect the
servers at on-rev.com and not intended for inclusion in the public
release for use on other hosts.

That said, 30 seconds is a LONG time on a server.  In Internet time,
it's close to "forever".  Add normal network latency and browser
rendering time to that and you've got some serious user expectation issues.

What server-side process could need that much time, and how many users
will wait for it?

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Jerry Daniels-2
In reply to this post by Michael Kann
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 <[hidden email]> wrote:
>
> From: Jerry Daniels <[hidden email]>
> Subject: Re: [revServer] process timeout issue
> To: "How to use Revolution" <[hidden email]>
> 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 <[hidden email]> wrote:
>>
>> From: Andre Garzia <[hidden email]>
>> Subject: Re: [revServer] process timeout issue
>> To: "How to use Revolution" <[hidden email]>
>> 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 <[hidden email]> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>>
>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Jerry Daniels-2
In reply to this post by Richard Gaskin
Richard, read my recent post on this.

On Aug 2, 2010, at 9:29 AM, Richard Gaskin wrote:

> I agree there should be no such limit in any server-side engine, and would be willing to bet this was put into RevServer to protect the servers at on-rev.com and not intended for inclusion in the public release for use on other hosts.
>
> That said, 30 seconds is a LONG time on a server.  In Internet time, it's close to "forever".  Add normal network latency and browser rendering time to that and you've got some serious user expectation issues.
>
> What server-side process could need that much time, and how many users will wait for it?
>
> --
> Richard Gaskin
> Fourth World
> Rev training and consulting: http://www.fourthworld.com
> Webzine for Rev developers: http://www.revjournal.com
> revJournal blog: http://revjournal.com/blog.irv
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Richard Gaskin
In reply to this post by Robert Mann
Jerry wrote:

 > 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.

Thanks for the clarification.

Since RevServer spawns a separate process for each request, how and why
does it bother limiting aggregate usage?

I suspect this is a bug and will be addressed in the next build.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Jerry Daniels-2
Richard,

For us, revServer is a black box that we don't have the time or inclination to deal with, at this point. Others, of course, may not be in the same situation we are in.

I do think revServer has the most potential of all the products Runrev sells. It just needs some docs, and, perhaps fixes.

JD
On Aug 2, 2010, at 10:02 AM, Richard Gaskin wrote:

> Jerry wrote:
>
> > 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.
>
> Thanks for the clarification.
>
> Since RevServer spawns a separate process for each request, how and why does it bother limiting aggregate usage?
>
> I suspect this is a bug and will be addressed in the next build.
>
> --
> Richard Gaskin
> Fourth World
> Rev training and consulting: http://www.fourthworld.com
> Webzine for Rev developers: http://www.revjournal.com
> revJournal blog: http://revjournal.com/blog.irv
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Pierre Sahores-3
In reply to this post by Richard Gaskin
And, in my experience, most of both the end-users and Google don't like to wait more than 6-8 seconds for an acceptable page load in response to any request send to a production state n-tier app.

About the question of the 64Mb memory limit, i just can't understand what kind of n-tier app request would need to use such an among of RAM ?!! Any explainations about such kind of needs in the Rodeo Env. would probably help us to purpose alternative ways to go...

I builded lots of PHP3/4/5 (+ Rev) n-tiers apps over the 15 last years and my httpd + php.ini configs went always configured to limit the requests timout in betwin 30-60 seconds and the among of RAM allowed to each PHP request to 2-4 Mb.

Hope this can help.

Best, Pierre


Le 2 août 2010 à 16:29, Richard Gaskin a écrit :

> That said, 30 seconds is a LONG time on a server.  In Internet time, it's close to "forever".  Add normal network latency and browser rendering time to that and you've got some serious user expectation issues.
>
> What server-side process could need that much time, and how many users will wait for it?

--
Pierre Sahores
mobile : (33) 6 03 95 77 70

www.woooooooords.com
www.sahores-conseil.com






_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Pierre Sahores-3
In reply to this post by Jerry Daniels-2

Le 2 août 2010 à 16:51, Jerry Daniels a écrit :

> 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.

Exact : i can see this happen with the early requests to woooooooords.com : The first request can, time to time, take around 20 secs. to get it's response back to the end-user's browser. After this first request, the next ones are always back to the user in less than some ticks. Could be a problem related to the RAM virtualisation of the RHEL5 host it self, httpd.conf, etc... and, please RunRev, we all need to get this fixed.

Best, Pierre

--
Pierre Sahores
mobile : (33) 6 03 95 77 70

www.woooooooords.com
www.sahores-conseil.com






_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Jerry Daniels-2
In reply to this post by Pierre Sahores-3
Pierre,

We have actual Rodeo customers who do analytics, and these processes can last 8hrs. Our server farm will cater to such tastes. This is a very lucrative market.

Best,

Jerry Daniels

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




On Aug 2, 2010, at 10:35 AM, Pierre Sahores wrote:

> About the question of the 64Mb memory limit, i just can't understand what kind of n-tier app request would need to use such an among of RAM ?!! Any explainations about such kind of needs in the Rodeo Env. would probably help us to purpose alternative ways to go...

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Jerry Daniels-2
In reply to this post by Pierre Sahores-3
Pierre,

It appears the requests are pooled or something because sometimes the timeouts are as low as 4 secs.

Best,

Jerry Daniels

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




On Aug 2, 2010, at 10:35 AM, Pierre Sahores wrote:

> I builded lots of PHP3/4/5 (+ Rev) n-tiers apps over the 15 last years and my httpd + php.ini configs went always configured to limit the requests timout in betwin 30-60 seconds and the among of RAM allowed to each PHP request to 2-4 Mb.

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Jerry Daniels-2
In reply to this post by Pierre Sahores-3
Pierre,

At first we thought revServer hiccup was a "wake-up call"--which is also not acceptable, but further investigation lead us to believe that is not the case. Some sort of pooling of requests within the 30 seconds seems a more logical explanation. However, this is academic to us. We've always factored our revServer code for the easiest possible migration to PHP, which we are now doing.

Best,

Jerry Daniels

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


On Aug 2, 2010, at 10:54 AM, Pierre Sahores wrote:

> Exact : i can see this happen with the early requests to woooooooords.com : The first request can, time to time, take around 20 secs. to get it's response back to the end-user's browser. After this first request, the next ones are always back to the user in less than some ticks. Could be a problem related to the RAM virtualisation of the RHEL5 host it self, httpd.conf, etc... and, please RunRev, we all need to get this fixed.





_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Richard Gaskin
In reply to this post by Robert Mann
Pierre Sahores wrote:

 > Exact : i can see this happen with the early requests to
 > woooooooords.com : The first request can, time to time, take
 > around 20 secs. to get it's response back to the end-user's
 > browser. After this first request, the next ones are always
 > back to the user in less than some ticks. Could be a problem
 > related to the RAM virtualisation of the RHEL5 host it self,
 > httpd.conf, etc... and, please RunRev, we all need to get
 > this fixed.

Why not just use the CGI engine in the meantime?

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Andre Garzia-3
In reply to this post by Pierre Sahores-3
Pierre,

I've just run 25 concurrent clients for 30 seconds against
wooooooooords.comand no request failed. The report is as follow:

Transactions:                  81 hits
Availability:              100.00 %
Elapsed time:               29.82 secs
Data transferred:            4.21 MB
Response time:                8.35 secs
Transaction rate:            2.72 trans/sec
Throughput:                0.14 MB/sec
Concurrency:               22.67
Successful transactions:          81
Failed transactions:               0
Longest transaction:           15.59
Shortest transaction:            3.39

You can see that the response time and transaction rate is pretty bad but
this is probably due to my bad network but the good news is that your server
sustained 25 concurrent clients for 30 seconds with no hiccup. 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.

Andre

On Mon, Aug 2, 2010 at 12:54 PM, Pierre Sahores <[hidden email]> wrote:

>
> Le 2 août 2010 à 16:51, Jerry Daniels a écrit :
>
> > 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.
>
> Exact : i can see this happen with the early requests to woooooooords.com: The first request can, time to time, take around 20 secs. to get it's
> response back to the end-user's browser. After this first request, the next
> ones are always back to the user in less than some ticks. Could be a problem
> related to the RAM virtualisation of the RHEL5 host it self, httpd.conf,
> etc... and, please RunRev, we all need to get this fixed.
>
> Best, Pierre
>
> --
> Pierre Sahores
> mobile : (33) 6 03 95 77 70
>
> www.woooooooords.com
> www.sahores-conseil.com
>
>
>
>
>
>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

Jerry Daniels-2
In reply to this post by Richard Gaskin
If a re-write of revServer code is necessary, why not re-write to another platform where you don't have to worry about timeouts, etc.?

Best,

Jerry Daniels

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




On Aug 2, 2010, at 11:09 AM, Richard Gaskin wrote:

> Pierre Sahores wrote:
>
> > Exact : i can see this happen with the early requests to
> > woooooooords.com : The first request can, time to time, take
> > around 20 secs. to get it's response back to the end-user's
> > browser. After this first request, the next ones are always
> > back to the user in less than some ticks. Could be a problem
> > related to the RAM virtualisation of the RHEL5 host it self,
> > httpd.conf, etc... and, please RunRev, we all need to get
> > this fixed.
>
> Why not just use the CGI engine in the meantime?
>
> --
> Richard Gaskin
> Fourth World
> Rev training and consulting: http://www.fourthworld.com
> Webzine for Rev developers: http://www.revjournal.com
> revJournal blog: http://revjournal.com/blog.irv
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: [revServer] process timeout issue

J. Landman Gay
In reply to this post by Robert Mann
On 8/2/10 6:11 AM, Robert Mann wrote:

> 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!

No need to obscure the name, this is a discussion that directly affects
Rev users, so it's appropriate here. I will follow it with interest.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
12345