[revServer] process timeout issue
chipp at chipp.com
Wed Aug 4 03:49:56 CDT 2010
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.
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
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.
More information about the use-livecode