(Interesting, Brian; I also were promised shell pretty soon about a year ago. It's a shame - MediaTemple has shell <i>and </i>also a breakdown of compute cycles per script...)<br><br>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. <br>
<br>Two questions:<br><ol><li>what is the most suitable Drupal function for this -- it needs to be something that runs regularly and for all kind of pages</li><li>for Drupal, is it enough to issue flush() or is ob_end_flush() also needed, or something else<br>
</li></ol>Thanks a million for any ideas;<br><br>Tomáš / Vacilando<br><br>
<br><br><div class="gmail_quote">On Thu, Feb 18, 2010 at 15:46, Brian Vuyk <span dir="ltr"><<a href="mailto:brian@brianvuyk.com">brian@brianvuyk.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
I've run into this with a few of my client sites, but they haven't even
been high-traffic sites. <br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br><font color="#888888">
<br>
Brian</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
Tomáš Fülöpp (<a href="http://vacilando.org" target="_blank">vacilando.org</a>) wrote:
<blockquote type="cite">Hi,<br>
<br>
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.<br>
<br>
<b>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.</b><br>
<br>
I've used Boost for anonymous pages, Parallel, Memcache, etc., all of
which helped and anonymous users <i>usually</i> 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.<br>
<br>
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.<br>
<br>
<b>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 <i>during </i>rendering of the page, then this
would be solved. </b><br>
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?<br>
<br>
<b>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.</b> 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!)<br>
<br>
Thank you for any ideas - on and off this list.<br>
<br>
Best regards,<br>
<br>
Tomáš / Vacilando<br>
<br>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br>