There was an excellent writeup about this set of issues here:<br><a href="http://mavergames.net/content/drupal-rackspace-clouds-cloud-sites-platform-some-tips-our-experiences">http://mavergames.net/content/drupal-rackspace-clouds-cloud-sites-platform-some-tips-our-experiences</a><br>
<br>I should mention that it's Rackspace Cloud Sites that is the problem - Rackspace Cloud Servers are quite good, aside from the fact that their network seems to get more than its share of DDOS attacks. There should be *no* password-controlled shell access to one of the servers though, as they're constantly under attack (as all wide-open VPSs on the internet are).<br>
<br>I certainly agree that hosting without shell access is a non-starter in any environment, and for that reason never even experimented with Cloud Sites.<br><br>-Randy<br><br><div class="gmail_quote">On Thu, Feb 18, 2010 at 10:08 AM, Matt Chapman <span dir="ltr"><<a href="mailto:matt@ninjitsuweb.com">matt@ninjitsuweb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Anyone who buys hosting without shell access is gonna get what they pay for...<br>
<br>
However, I do want to draw attention to the fact that the CloudSITES<br>
services is being discussed here. I have been using the Rackspace<br>
CloudSERVERS (similar to Amazon EC2, in concept) offering for a few<br>
months now, and I love it. It has not been plagued by the recent<br>
security issues, or any of the complaints I head about<br>
CloudSites/Mosso.<br>
<br>
My only problem has been a corrupted backup on one occasion, so as<br>
always, never trust someone else's backup of your data. That applies<br>
to any hosting service, so I highly recommend Rackspace CloudServers.<br>
<br>
All the Best,<br>
<br>
Matt Chapman<br>
Ninjitsu Web Development<br>
<font color="#888888"><br>
--<br>
The contents of this message should be assumed to be Confidential, and<br>
may not be disclosed without permission of the sender.<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On Thu, Feb 18, 2010 at 8:38 AM, Tomáš Fülöpp (<a href="http://vacilando.org" target="_blank">vacilando.org</a>)<br>
<<a href="mailto:tomi@vacilando.org">tomi@vacilando.org</a>> wrote:<br>
> (Interesting, Brian; I also were promised shell pretty soon about a year<br>
> ago. It's a shame - MediaTemple has shell and also a breakdown of compute<br>
> cycles per script...)<br>
><br>
> Anyway -- Victor's note about shortening PHP timeout brought me to thinking<br>
> about measuring the time since the start of the execution and issuing<br>
> flush() each time the process might time out.<br>
><br>
> Two questions:<br>
><br>
> what is the most suitable Drupal function for this -- it needs to be<br>
> something that runs regularly and for all kind of pages<br>
> for Drupal, is it enough to issue flush() or is ob_end_flush() also needed,<br>
> or something else<br>
><br>
> Thanks a million for any ideas;<br>
><br>
> Tomáš / Vacilando<br>
><br>
><br>
><br>
> On Thu, Feb 18, 2010 at 15:46, Brian Vuyk <<a href="mailto:brian@brianvuyk.com">brian@brianvuyk.com</a>> wrote:<br>
>><br>
>> I've run into this with a few of my client sites, but they haven't even<br>
>> been high-traffic sites.<br>
>><br>
>> Personally, I just don't think the RS Cloud is a good match for Drupal.<br>
>> Combine that with the recent security issues they've had, occasional<br>
>> inexplicable downtime, the 'no suitable nodes' and the lack of a shell, and<br>
>> I am moving my sites away as quick as I can.<br>
>><br>
>> The shell issue is really sensitive for me - about 14 months ago, my<br>
>> previous host ran into... issues... and could no longer offer hosting. So, I<br>
>> was in a pinch and Rackspace (then Mosso) looked very good apart from the<br>
>> lack of a shell. I talked to their customer service reps, and was informed<br>
>> that shell access for the cloud was in pre-release testing, and was<br>
>> scheduled to go live the next week.<br>
>><br>
>> In a burst of poor judgement, I decided that the package they offered was<br>
>> good enough to do without shell access for a week, so I bought in, and<br>
>> transferred my sites. 14 months later, shell access still hasn't been<br>
>> released, and I've had to move all my more critical / development-intensive<br>
>> sites off of their service in the meantime.<br>
>><br>
>> Brian<br>
>><br>
>><br>
>><br>
>> Tomáš Fülöpp (<a href="http://vacilando.org" target="_blank">vacilando.org</a>) wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> At RackspaceCloud (former Mosso) I've been plagued with a very unfortunate<br>
>> problem that i crippling both my work and the work of my clients -- namely<br>
>> the infamous error message "Unfortunately there were no suitable nodes<br>
>> available to serve this request." Those of you at RS Cloud must have bumped<br>
>> into it. It is cryptic and happens unpredictably. The cloud is very stable<br>
>> and scalable, but for any a little bit heavier Drupal installation people do<br>
>> start getting these errors.<br>
>><br>
>> Basically, it is a generic error thrown by load balanced systems that<br>
>> occurs as a result of a script exceeding a maximum timeout value (not the<br>
>> PHP timeout value!) If a client connection does not receive a response from<br>
>> the server after approximately 30 to 60 seconds the load balancer will close<br>
>> the connection and the client will immediately receive the error message. In<br>
>> most cases, the script will continue to execute until it reaches completion,<br>
>> throws an error, or times out on the server, but the client will not see the<br>
>> page load as expected and will instead receive this error.<br>
>><br>
>> I've used Boost for anonymous pages, Parallel, Memcache, etc., all of<br>
>> which helped and anonymous users usually don't get this error. The problem<br>
>> is with admin or any other a bit heavier work of logged in users. Even for<br>
>> basic Drupal websites with not too many modules! Pages like the list of<br>
>> modules, or the status page, i.e. heavy database or file requests, or API<br>
>> calls in PHP, are very likely to time out.<br>
>><br>
>> Over the past year I've had a number of discussions with techs and admins<br>
>> at that cloud, but the situation is unresolved. They recognize the problem<br>
>> but maintain this is due to the special/unusual setup they use for their<br>
>> cloud. It is not a problem for some other CMS / frameworks. E.g. a very<br>
>> heavy MediaWiki installation runs just fine. Drupal seems to be less<br>
>> compatible with their system, somehow, somewhere.<br>
>><br>
>> Now, why do I mention all this in the development list? I've been<br>
>> intrigued by one little ray of hope in their words: "if a client connection<br>
>> does not receive a response from the server after approximately 30 to 60<br>
>> seconds the load balancer will close the connection and the client will<br>
>> immediately receive the error message". Their techs said if I were able to<br>
>> emit any kind of intermediary response to the client during rendering of the<br>
>> page, then this would be solved.<br>
>> Indeed, a bit like the Batch API works in Drupal (with that I often run<br>
>> night-long scripts without problems). I wonder, maybe this is a more generic<br>
>> problem for any system that employs load balancers?<br>
>><br>
>> So my questions to you, colleagues, is -- do you see any place in Drupal<br>
>> processing chain that could be used, and approximately how, to make sure<br>
>> that the load balancer keeps the connection opened. If you have any ideas,<br>
>> wild or proven, I will be happy to test and develop them further and bring<br>
>> them back to the community, of course. If this succeeds, I think many of us<br>
>> will be relieved (and able to focus on development again!)<br>
>><br>
>> Thank you for any ideas - on and off this list.<br>
>><br>
>> Best regards,<br>
>><br>
>> Tomáš / Vacilando<br>
>><br>
>><br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Randy Fay<br>Drupal Development, troubleshooting, and debugging<br><a href="mailto:randy@randyfay.com">randy@randyfay.com</a><br>+1 970.462.7450<br><br>