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