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