[revServer] process timeout issue

Mon Aug 2 18:06:09 EDT 2010

Hello Wayne,

You welcome :-)

Best, Pierre

Le 2 août 2010 à 23:42, wayne durden a écrit :

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

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

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