[development] No suitable nodes available at RackspaceCloud (Mosso)

Tomáš Fülöpp (vacilando.org) tomi at vacilando.org
Thu Feb 18 22:14:17 UTC 2010


*Some* progress - but it still may be a dead end:

mikeytown2 suggested me to try to echo a comment in index.php. I instead
used flush(); there.
I cleared all caches and went to a heavy page (modules) and ... it loaded
for over a minute, then ended up *without* the "no suitable nodes" message!

The catch -- the resulting page was blank. I looked in logs and obviously
that was full of "PHP Warning: Cannot modify header information - headers
already sent in ...".

So the last question is - is there a way to reset the headers after
flush();... somehow tell the browser, while it is still waiting, that
it should
forget about the initial flush, now come the real headers and the page.
Alternatively, is there a possibility to output the headers earlier in the
process, as soon as possible, and then put this flush(); after that...?
That would be the solution!!

Inclined to hope again...

Let me know

Tomáš / Vacilando





On Thu, Feb 18, 2010 at 23:01, Cameron Eagans <cweagans at gmail.com> wrote:

> Yeah...it's now deprecated, but new users who don't know any better
> like to use it for some reason =P
> -----
> Cameron Eagans
> Owner, Black Storms Studios, LLC
> http://www.blackstormsstudios.com
>
>
>
> On Thu, Feb 18, 2010 at 12:38 PM, Matt Chapman <matt at ninjitsuweb.com>
> wrote:
> > Modules page...? ...
> >
> > Oh, is that the thing we used before drush...?  ;-)
> >
> >
> > 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 11:30 AM, Cameron Eagans <cweagans at gmail.com>
> wrote:
> >> I dunno....I've run Drupal on some really slow servers, and the
> >> modules page can take a LONG time to render. I guess it kind of
> >> depends on the hardware they're using for Mosso, but I do agree with
> >> the sentiment that it's probably not a timeout issue.
> >>
> >> @Tomáš: If I were in your shoes and an issue like this was unresolved
> >> after a year, I think I'd be strongly considering a new hosting
> >> provider. Slicehost is fantastic. EC2 is a pretty good choice too (you
> >> can just spin up the Mercury AMI and have a really sweet Drupal
> >> hosting setup). I hear good things about Linode too.
> >> -----
> >> Cameron Eagans
> >> Owner, Black Storms Studios, LLC
> >> http://www.blackstormsstudios.com
> >>
> >>
> >> On Thu, Feb 18, 2010 at 12:23 PM, larry at garfieldtech.com
> >> <larry at garfieldtech.com> wrote:
> >>>
> >>> Drupal by design doesn't generate output of any kind until the last
> second, and then sends the entire page as one giant string.  That is what
> allows us to do all sorts of fun things in the theme layer or HTTP
> redirection before content gets sent.
> >>>
> >>> That said, if I understood the original message Rackspace is saying the
> proxy server is timing out after 30 *seconds* of no response?  Even the
> heaviest Drupal page shouldn't get anywhere near that time.  3-4 seconds for
> something other than selected admin pages is considered an eternity, at
> least for the PHP time.  There's something else going on here besides Drupal
> not being the fastest PHP app out there...
> >>>
> >>> --Larry Garfield
> >>>
> >>> Tomáš Fülöpp (vacilando.org) 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:
> >>>>
> >>>>   1. what is the most suitable Drupal function for this -- it needs to
> >>>>      be something that runs regularly and for all kind of pages
> >>>>   2. 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 <brian at brianvuyk.com<mailto:
> brian at brianvuyk.com>> 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 <http://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
> >>>>>
> >>>>
> >>>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20100218/143a0a04/attachment-0001.html 


More information about the development mailing list