[revServer] process timeout issue

[Jerry Daniels]

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