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.dani...@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@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution