[revServer] process timeout issue

Mon Aug 2 17:42:05 EDT 2010

Hello Pierre,

I just wanted to chime in that I appreciate the details you have provided in
this thread and the benchmarks which Andre has helped flesh out...  It helps
some of us coming to this platform a little later evaluate its suitability
for additional projects.

Rev has proved excellent for me with regard to desktop apps, and a handful
of CGI's I have built are encouraging but I have always wondered about
issues of scale.  Details like these are indeed helpful when they crop up.

Thanks for the posting all around.

Wayne

On Mon, Aug 2, 2010 at 5:11 PM, Jerry Daniels <jerry.daniels at me.com> wrote:

> Pierre,
>
> I appreciate your counsel. I do. But, I have to go with my own experience
> and Sarah's on this one. And I'm pretty sure it's not the architecture or
> the code. We've done very granular tests.
>
> We've got a pretty good team of experts, ourselves--some trained by the
> people who invented n-tier architecture. We HAVE run our findings, back-end
> design and architecture by experienced technicians with actual success in
> our space. I think we've made a good decision. But that decision is for
> us...I'm not trying to put that on anyone else.
>
> As I said, I use revServer for lots of stuff. But just not this one thing.
> I think my motives and intent have been fairly obscured by now, so I'm going
> to give it a rest. I think I'm ruining Kevin's bank holiday.
>
> Best,
>
> Jerry
>
>
> On Aug 2, 2010, at 3:59 PM, Pierre Sahores wrote:
>
> > Jerry,
> >
> > In my experience, Rev went always able to let me serve rock-solid n-tier
> apps. It makes yet more than one year that i test extensively the revServer
> technology and all worked as well as what i can handle in using my "PHP
> sockets-listener + Rev application's server" 15 years polished solution.
> >
> > At this point, i don't suspect the revServer to be responsable at all
> from the problem i reported below because each time i had to do with such
> latence in starting a first Apache binded request (as cgi or standard html
> page), it always had, over the years and on many different provider's
> backbones in France and in the USA, to do with the amount of RAM of the
> hosting machine, never with Rev.
> >
> > I wants to be clear there :
> >
> > - A server is not suited to handle Desktop's ilike process : if some one
> asked me if i would accept to host, on my own server, a n-tier app witch
> would have to use 64 Mb of RAM per process or thread, i would just answer
> "NO". Nor PHP, Python, Ruby, Perl, Rev, MC, Java are suited to run such kind
> of requests.
> >
> > - As you could see in the "ab" woooooooords.com test i reported
> previously, revServer was able to reply to 100% of the 1550 requests ab
> sended in 30 secs. This is a very good result for a mutualised server and i
> fell 100% happy about it
> >
> > - 64 Mb * 1550 = 96 Gb : you just cant expect this can work at all ....
> on any current well suited Linux server. Instead, you will need to do what
> we always do to reduce the amount of RAM needed by each http thread /
> process : replace all your revServer "direct to RAM+flat-files" processes
> management by revServer+ SQL backend processes management and Rodeo will
> become compatible with all the n-tier standard requierements. Else, you will
> never get best results in trying to implement your "direct to
> RAM+flat-files" logic in PHP, Java, Python or Perl.
> >
> > My feeling is that Rev and revServer are'nt responsable at all from the
> problem you are reporting us : you just need to redesign your code from a
> n-tier logic point of view and in doing this you will see that the
> revServer, even if it is still in its early stage, is from yet a very
> competitive n-tier technology. Along my Master2 of n-tier application's
> design, i had to build projects in J2SE, PHP, Rebol, AJAX, and more and, you
> know what, Rev was and is still my prefered n-tier platform and PHP is far
> from able to compete in about big projects alike Rodeo seems to be suited to
> become ...
> >
> > There are some n-tier experts around on this list, Richard, Andre and
> some others and i think you can trust them when they say that there is no
> blackbox at all behind revServer : it's only the xtalk engine we knows
> about. It's just a great piece of code witch let me now do anything i need
> without having to rely on my obsolete "PHP sockets listener + Rev" way to
> go.
> >
> > I just hope Kevin, Mark, Oliver and all, at Edimburg will provide us the
> "protected stacks libs support" as soon as possible and, perhaps, a coolest
> revServer installer in the same time ;-)
> >
> > Kind Regards,
> >
> > Pierre
> >
> >
> >
> >
> >
> >> 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
> >
> > --
> > Pierre Sahores
> > mobile : (33) 6 03 95 77 70
> >
> > www.woooooooords.com
> > www.sahores-conseil.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
>
> _______________________________________________
> 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
>