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, [email protected] <[email protected]> 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 <[email protected] >> <mailto:[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 <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 >>> >> >>
