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
