Peter, I also have budget accounts with Jupiter, iPowered and one other, and you're right-- you get what you paid for. I suspect as founding members, there was a time when our bandwidth and server performance may have been blistering-- I don't know, I didn't test it.
But, as you may not know, this discussion isn't about that-- it's about trying to figure out what the problem Jerry was having that forced him to move to a different platform-- and all the bruhaha surrounding it. All I was/am trying to do is to point out there never was a recipe or a basic understanding of what the actual problem was. While typically it's bad form to 'repost' someone else's findings, I don't believe Kevin nor Andre Garzia would mind me sharing what Andre has found out over with regard to RevServer. From Andre: I believe the limits are not on RevServer itself but on the virtualization > stack used on On-Rev. I have RevServer running on my own web server here and > I just did two tests: * A RevServer script that takes 40 seconds to load. * A RevServer script that uses 90MB of memory. * A RevServer script that uses 225MB and takes 40 seconds to load. http://andregarzia.com/memory.irev http://andregarzia.com/40secs.irev http://andregarzia.com/supertest.irev Then I've run 30 requests at 5 concurrency level against memory.irev. The memory one completed without a single failure, it completed in 7 seconds for all the 30 requests, no errors, timeouts or hiccups. I could not use "ab" to test the ones with a wait in them because my "ab" is not honoring the timeout settings. So if I set the timeout to 2 minutes, it still timeout at couple seconds. Bug on my side not the RevServer side, all pages load fine on the web. So now we know scripts can take forever to run (40 seconds is forever) and use big amount of RAM (225MB). I am using http://jaguarpc.com with their VPS TWO plan. So, this seems to point to the configuration of the on-rev servers and not the RevServer architecture. That's a place to start and I hope the Rev engineers will look into it. I'll also reference a number of above requests by knowledgeable folks like Richard and Andre for information regarding this problem which have still gone unanswered. My point is to keep from spreading innuendo and disinformation which lead to comments like the ones on rodeoapps.posterous.com: "This time out deep burried limitation seems to me like a bomb : since I have built recent plans on on-rev." "Oh my god... This is a bad news." "I guess your guys with Rodeo, the first "large" use of RevServer, are like the canary in the coal mine." "The issues of script memory limitation and timeout have been in my opinion barriers to serious work on On-Rev since it's launch in 2009." "While I think it's obvious that Rodeo was going to split from Rev all along, my experiences with On-Rev have left me unlikely to use Rev products again in the future... You are right; using PHP is a far better choice." I imagine anyone Googling for information on RevServer would certainly find those. They do damage-- and deserve a rebuttal. But, of course, without a recipe or any sort of proof, a rebuttal is pretty much impossible. That is why I've called on Jerry to try and work with RR to create a recipe so that a fix can be found. Frankly, I was pretty much taken by surprise when Jerry posted his issue with RevServer so publicly, especially when Kevin has most generously allowed Jerry and company to harvest customers directly from this list-- something I have never seen another company do. _______________________________________________ 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