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