Jerry Daniels wrote:
> This thread has repeatedly gone from the revServer timeout issue
> to personalities, Rodeo and its choice of technologies.
Respectfully, may I note that the last several posts on this (from Sean,
Andre, Michael, and myself) have attempted to help focus the discussion
on a rational analysis of the problem suggested, looking at this as a
RevServer issue and not a Rodeo-specific one. Given the potential
usefulness of this new product, I think it's helpful to continue its
exploration along these lines.
If Oliver's comment about "iRev" meant to refer to on-rev.com (which it
turns out was the subject of that thread -- see
<http://forums.runrev.com/phpBB2/viewtopic.php?f=8&t=4791>), the
situation is readily understandable and poses no problem to anyone
wanting to use RevServer on a dedicated server. Shared-hosting servers
commonly impose such limits on all processes, including PHP, and for
good reason. Anyone wanting to dominate a machine's CPU would expect to
use a dedicated server.
If instead Oliver's comment was referring to the RevServer engine itself
then it would indeed limit the appeal of the product for use on
dedicated servers, but we have yet to determine:
a) whether that's the case.
b) if it is, whether that's the intended behavior when using RevServer
on a dedicated server or is merely a bug which could be fixed in the
next build.
c) how it's even possible for a single child process to govern aggregate
server-wide limits (if it is there may be some useful hacks and/or
interesting security exposures worth exploring).
So far the analysis provided by Andre and Pierre suggests that any
limits on cycles or memory exit only in the common configs for shared
hosting services such as on-rev.com and are not specific to the
RevServer engine itself. Andrew Dickey's astute comments in the forum
and the improve-rev list refer only to on-rev.com; I haven't yet seen
claims that such limits have been observed on a dedicated server.
For my own part, while I have no experience with RevServer itself yet
I've done enough work on public sites using Rev CGI that I know the
RunRev team is capable of delivering a robust, flexible engine that
performs on par or better than many alternatives (Rev's well-optimized
chunk expressions rule for many server tasks). One of the systems I've
developed is used by hundreds of hospitals worldwide with Rev-based CGIs
handling login, registration, and even a custom search engine and it's
held up quite well, so I feel we all have good reason expect the same of
at least the release version of RevServer if not the version we have
available now.
I have no opinion about Rodeo or its choice of technologies, and as far
as personalities go I like yours a lot and like many here regard Sarah
as a generous code goddess. :)
My interest here is simply that I have a lot of resources invested in
the Rev CGI and may migrate some of those to RevServer, so it's useful
for me and anyone else here considering RevServer to pursue a solid
understanding of that engine.
--
Richard Gaskin
Fourth World
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
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
