<i>Some</i>Â progress - but it still may be a dead end:<div><br></div><div>mikeytown2 suggested me to try to echo a comment in index.php. I instead used <font class="Apple-style-span" face="'courier new', monospace">flush();</font> there.</div>
<div>I cleared all caches and went to a heavy page (modules) and ... it loaded for over a minute, then ended up <u>without</u> the "no suitable nodes" message!</div><div><br></div><div>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 ...".</div><div><br></div><div>So the last question is - is there a way to reset the headers after <font class="Apple-style-span" face="'courier new', monospace">flush();</font> ... 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.</div>
<div>Alternatively, is there a possibility to output the headers earlier in the process, as soon as possible, and then put this flush(); after that...? </div><div>That would be the solution!!</div><div><br></div><div>Inclined to hope again... </div>
<div><br></div><div>Let me know</div><div><br></div><div>Tomáš / Vacilando</div><div><br></div><div>
<br><div><br></div><div><br><br><div class="gmail_quote">On Thu, Feb 18, 2010 at 23:01, Cameron Eagans <span dir="ltr"><<a href="mailto:cweagans@gmail.com">cweagans@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Yeah...it's now deprecated, but new users who don't know any better<br>
like to use it for some reason =P<br>
<div class="im">-----<br>
Cameron Eagans<br>
Owner, Black Storms Studios, LLC<br>
<a href="http://www.blackstormsstudios.com" target="_blank">http://www.blackstormsstudios.com</a><br>
<br>
<br>
<br>
</div><div><div></div><div class="h5">On Thu, Feb 18, 2010 at 12:38 PM, Matt Chapman <<a href="mailto:matt@ninjitsuweb.com">matt@ninjitsuweb.com</a>> wrote:<br>
> Modules page...? ...<br>
><br>
> Oh, is that the thing we used before drush...? Â ;-)<br>
><br>
><br>
> All the Best,<br>
><br>
> Matt Chapman<br>
> Ninjitsu Web Development<br>
><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>
><br>
><br>
><br>
> On Thu, Feb 18, 2010 at 11:30 AM, Cameron Eagans <<a href="mailto:cweagans@gmail.com">cweagans@gmail.com</a>> wrote:<br>
>> I dunno....I've run Drupal on some really slow servers, and the<br>
>> modules page can take a LONG time to render. I guess it kind of<br>
>> depends on the hardware they're using for Mosso, but I do agree with<br>
>> the sentiment that it's probably not a timeout issue.<br>
>><br>
>> @Tomáš: If I were in your shoes and an issue like this was unresolved<br>
>> after a year, I think I'd be strongly considering a new hosting<br>
>> provider. Slicehost is fantastic. EC2 is a pretty good choice too (you<br>
>> can just spin up the Mercury AMI and have a really sweet Drupal<br>
>> hosting setup). I hear good things about Linode too.<br>
>> -----<br>
>> Cameron Eagans<br>
>> Owner, Black Storms Studios, LLC<br>
>> <a href="http://www.blackstormsstudios.com" target="_blank">http://www.blackstormsstudios.com</a><br>
>><br>
>><br>
>> On Thu, Feb 18, 2010 at 12:23 PM, <a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a><br>
>> <<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>> wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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...<br>
>>><br>
>>> --Larry Garfield<br>
>>><br>
>>> Tomáš Fülöpp (<a href="http://vacilando.org" target="_blank">vacilando.org</a>) wrote:<br>
>>>><br>
>>>> (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...)<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>
>>>><br>
>>>> Â 1. what is the most suitable Drupal function for this -- it needs to<br>
>>>> Â Â Â be something that runs regularly and for all kind of pages<br>
>>>> Â 2. for Drupal, is it enough to issue flush() or is ob_end_flush()<br>
>>>> Â Â Â also needed, 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> <mailto:<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<br>
>>>> Â Â even been high-traffic sites.<br>
>>>><br>
>>>> Â Â Personally, I just don't think the RS Cloud is a good match for<br>
>>>> Â Â Drupal. Combine that with the recent security issues they've had,<br>
>>>> Â Â occasional inexplicable downtime, the 'no suitable nodes' and the<br>
>>>> Â Â 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<br>
>>>> Â Â previous host ran into... issues... and could no longer offer<br>
>>>> Â Â hosting. So, I was in a pinch and Rackspace (then Mosso) looked very<br>
>>>> Â Â good apart from the lack of a shell. I talked to their customer<br>
>>>> Â Â service reps, and was informed that shell access for the cloud was<br>
>>>> Â Â 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<br>
>>>> Â Â offered was good enough to do without shell access for a week, so I<br>
>>>> Â Â bought in, and transferred my sites. 14 months later, shell access<br>
>>>> Â Â still hasn't been released, and I've had to move all my more<br>
>>>>   critical  / development-intensive sites off of their service in the<br>
>>>> Â Â meantime.<br>
>>>><br>
>>>> Â Â Brian<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>>   Tomáš Fülöpp (<a href="http://vacilando.org" target="_blank">vacilando.org</a> <<a href="http://vacilando.org" target="_blank">http://vacilando.org</a>>) wrote:<br>
>>>>><br>
>>>>> Â Â Hi,<br>
>>>>><br>
>>>>> Â Â At RackspaceCloud (former Mosso) I've been plagued with a very<br>
>>>>> Â Â unfortunate problem that i crippling both my work and the work of<br>
>>>>> Â Â my clients -- namely the infamous error message "Unfortunately<br>
>>>>> Â Â there were no suitable nodes available to serve this request."<br>
>>>>> Â Â Those of you at RS Cloud must have bumped into it. It is cryptic<br>
>>>>> Â Â and happens unpredictably. The cloud is very stable and scalable,<br>
>>>>> Â Â 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<br>
>>>>> Â Â that occurs as a result of a script exceeding a maximum timeout<br>
>>>>> Â Â value (not the PHP timeout value!) If a client connection does not<br>
>>>>> Â Â receive a response from the server after approximately 30 to 60<br>
>>>>> Â Â seconds the load balancer will close the connection and the client<br>
>>>>> Â Â will immediately receive the error message. In most cases, the<br>
>>>>> Â Â script will continue to execute until it reaches completion,<br>
>>>>> Â Â throws an error, or times out on the server, but the client will<br>
>>>>> Â Â not see the page load as expected and will instead receive this<br>
>>>>> Â Â error.*<br>
>>>>><br>
>>>>> Â Â I've used Boost for anonymous pages, Parallel, Memcache, etc., all<br>
>>>>> Â Â of which helped and anonymous users /usually/ don't get this<br>
>>>>> Â Â error. The problem is with admin or any other a bit heavier work<br>
>>>>> Â Â of logged in users. Even for basic Drupal websites with not too<br>
>>>>> Â Â many modules! Pages like the list of modules, or the status page,<br>
>>>>> Â Â i.e. heavy database or file requests, or API calls in PHP, are<br>
>>>>> Â Â very likely to time out.<br>
>>>>><br>
>>>>> Â Â Over the past year I've had a number of discussions with techs and<br>
>>>>> Â Â admins at that cloud, but the situation is unresolved. They<br>
>>>>> Â Â recognize the problem but maintain this is due to the<br>
>>>>> Â Â special/unusual setup they use for their cloud. It is not a<br>
>>>>> Â Â problem for some other CMS / frameworks. E.g. a very heavy<br>
>>>>> Â Â 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<br>
>>>>> Â Â connection does not receive a response from the server after<br>
>>>>> Â Â approximately 30 to 60 seconds the load balancer will close the<br>
>>>>> Â Â connection and the client will immediately receive the error<br>
>>>>> Â Â message". Their techs said if I were able to emit any kind of<br>
>>>>> Â Â 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<br>
>>>>> Â Â often run night-long scripts without problems). I wonder, maybe<br>
>>>>> Â Â this is a more generic problem for any system that employs load<br>
>>>>> Â Â balancers?<br>
>>>>><br>
>>>>> Â Â *So my questions to you, colleagues, is -- do you see any place in<br>
>>>>> Â Â Drupal processing chain that could be used, and approximately how,<br>
>>>>> Â Â to make sure that the load balancer keeps the connection opened.*<br>
>>>>> Â Â If you have any ideas, wild or proven, I will be happy to test and<br>
>>>>> Â Â develop them further and bring them back to the community, of<br>
>>>>> Â Â course. If this succeeds, I think many of us will be relieved (and<br>
>>>>> Â Â 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>
><br>
</div></div></blockquote></div><br></div></div>