Local installations of Drupal on Windows Vista load slowly or fail

I have found problem... PHP script for "administer" page is generated during 40 seconds and default PHP timeout is not enough to execute this script.

So, how can I speed up script generation?.. I think this is bug, because CPU usage is low (5-7%).

I'm running into the same problem.

Here's my experience... I tested Drupal 6.0 and XAMPP 1.6.6 on XP Home Edition using IE7. All "vanilla" install except instead of "htdocs" for the web-root I made another directory called "Webroot" elsewhere, so no biggy. Everything worked fine. There's the control.

I installed the exact same setup on my Vista Ultimate Edition computer with IE7, which I would rather devel on as the XP computer is a laptop, and that's when the problem arose... Everything seems to be working aside from the Administer link. Just hangs, almost no processor usage what-so-ever, and the the blank page after about a 30-40 second timeout.

I have the same issue on a Vista Ultimate system running XAMPP. The cause is likely the Update status module's check for the latest versions of installed modules. One quick work-around that works for me is to skip directly to the modules page (q=admin/build/modules) and temporarily disable Update status. I suspect that there is a setting in the XAMPP configuration that is preventing the status check from making outbound HTTP requests, but I haven't debugged it yet.

And it gets stranger.... check this out. I figured what the hey, dumped the database, made a fresh one, did another fresh install of drupal, went through the setup, but this time the changed anything "localhost" to "127.0.0.1" and guess what... makes no sense, but now when I goto Administer, less laggy and the link works...

So the update status from your results and the localhost "resolution??" to 127.0.0.1 may somehow be tied together?? hmmm... go figure. I'm wondering if somewhere in the Update Status code it's trying to talk to localhost or something, and Vista gets confused?, hanging up/timing out the module, and then Drupal says we better spit out the Blank Page Of Death... Since I did 127.0.0.1 maybe Vista doesn't get confused??

Your guess is as good as mine at this point, but at least we have some progress...
On a sidenote this may not be a "bug" with drupal, but instead a bug with Vista's handling of localhost...

Ergose

Well, wasn't going to post again tonight, but I was still getting the lag on alot of the drupal pages even though the Blank Page problem cleared up, and found a solution to the "bugs"...

On Vista (As it appears to be where the problems lie...) if using Drupal locally for devel...

Change any localhosts on setup to 127.0.0.1 to fix blank page on administer bug.

Instead of localhost in IE7, and I ran across similar with Firefox on google, again do 127.0.0.1 to get rid of the roughly 10-15secs lag left over that is unaccounted for(in essence a separate "bug").

So as far as I'm concerned Vista is the most likely culprit...

Resolved?
Can we have drupal put up a notification or something on install?

Ergose

Based on your comments above, I did some googling and discovered that there are *lots* of results for "localhost 127.0.0.1 vista", and general consensus that some versions of Vista have a buggy implementation of IPv6 (that, according to some reports, becomes especially apparent when one uses Firefox).

There were a number of suggested fixes, and I didn't read through all of them. I tried:
- disabling IPv6 in Network Connections, but this didn't fix it for me.
- making sure that c:\windows\system32\drivers\etc\hosts contained a mapping from 127.0.0.1. It did.
- used about:config to set network.dns.disableIPv6 in Firefox. This didn't help.
- added a "# " before the line "::1" in c:\windows\system32\drivers\etc\hosts to force vista to use the IPv4 mapping for localhost. This worked for me, and solved the issue in both IE and FF. Things are working very snappy now.

I am still having a problem fetching updates on this box, but that is likely another issue (I think), especially if other folks with similar problems as described here are fetching updates fine.

If other people with similar problems can try out some of the suggested fixes (or google for others), I will write up the results into a documentation page in the Troubleshooting section.

Thanks for posting all of that. Removing/Commenting out the mapping I considered a last resort and didn't have the time to test it out as I had been up all night tracking down this bug instead of develing like I was supposed to, but things going that sluggish really puts a kink on the devel side of things. I had a feeling it would work though, but being that the 127.0.0.1 thing worked for my purposes I went ahead and started working on the website so I could actually get some work done. I swear if the implementation of IPv6 was buggy on Vista, they should have had it autodetect 4 or 6 and use 4 only by default and 6 if the internal network is set as such... on the latter they could have just put up a check box that says tunnel ip6 through 4 on this or that network to cover laptop people connecting to their intranet over an ip4 connection... Why Microsoft does as they do on these kind of things I'll never know.

I guess since this isn't really a drupal bug, nothing has to be done, but a notifictaion somewhere saying "Drupal has detected you are running on Vista with Drupal on localhost. There are known bugs with Vista's IPv6 Stack that may cause sluggishness and a blank page when accesing the Administer section. Try .... in your hosts file to see if this corrects the problem. This is a known bug with Vista, not Drupal and there is extensive documentation on similar hangups... see here here and here for more details concerning this bug..." would be welcomed as I could have checked that and got things working in about 5-10min leaving the rest of the night to code.

Ergose

Though this may be a separate issue, I'm curious -- does your update status module retrieve release information correctly (or at all)?

Not sure... The XP at the house did fine using localhost and everything. The Vista one however is not, but I have assumed that has to do with not being able to authenticate with the proxy/firewall here at work. I figured I'd just check to see the address the module uses to check updates with and tell the admin to let it through. However it sounds like you caught a possible caveat I had not forseen. Why is yours not working? If not I'll go ahead and have him allow it through and get back to you with more data.

No, update status on this same Vista box does NOT work. Sometimes I'll get an outbound connections error on the status page, but most often not. I thought it might be a setting in XAMPP causing this but so far I don't see anything unusual there. I want to say that an earlier version of head did work, so perhaps something has changed, but I'm not 100% sure about that.

That little # did the trick for me (running on Vista home addition and the wamp apache server) Thank you very much.

This fixed my problem as well. It's a good thing to keep in mind when someone's complaining about admin not working on D6 in #drupal - I'll definately keep it in mind!

I have the same problem, but not with Vista and 127.0.0.1 did not help. For a while it worked fine after the install. After that I added a new content type, a new user and added some permissions and rules. I also used two browsers (IE and FF) parallel to log in as admin and new user. Somewhen that time it started halting.

Windows XP Professional SP2
Drupal 6.1
WAMP 2.0b
- Apache 2.2.8 (on port 8080 because of Skype)
- PHP 5.2.5
- MySQL 5.0.51a
FSecure

Changing php max_execution_time value from 30 secs to 60 secs helped, the page appears after around 30 secs.

Any ideas?

Gabor

I see this problem repeatedly on my Vista laptop (Dell Inspiron 1525, bought in April) and not at all on my XP desktop. What's interesting is that I was able to do the installation successfully on the same Vista laptop just a few weeks ago, but then my system ran into problems (caused by something else) and I had to have the hard drive reformatted, probably with the newest drivers. Since then, it hasn't worked.

Using "127.0.0.1" rather than "localhost" in the path in the address bar did not help me. I'd like to try editing the hosts file, but the system refused me the right to save the hosts file, even though the attributes indicated that I had read/write access. I'm going to see whether I can get to it in safe mode or via some other means.

I posted the following comment to http://drupal.org/node/221226 as well:

So far, I have not been able to fix the problem on my Vista laptop by doing any of the following (some of which have been reported as working for others):
- renaming .htaccess to .htaccess.bak.txt
- editing \windows\system32\drivers\etc\hosts to insert a '#' before the '::1' (note: I needed to be in "Safe Mode with Command Prompt" to edit the file)
- using "127.0.0.1" rather than "localhost" in the path
- using "Intranet Settings" in Internet Explorer

Note that the problem didn't appear:
- on my XP desktop, using the exact same version of 6.2
- on my Vista laptop (Dell Inspiron 6.2) before I reformatted the drive (which was experiencing errors) and got the latest drivers from Dell
- when installing 5.7 on the Vista laptop

Have you tried #4?

I assume #17 was a question for me. It asked whether I'd tried #4, which said:
"The cause is likely the Update status module's check for the latest versions of installed modules. One quick work-around that works for me is to skip directly to the modules page (q=admin/build/modules) and temporarily disable Update status."

But I don't know how I would do that. I can't even complete installation, so I don't know how I would skip to the modules page.

How about this from #14:

"Changing php max_execution_time value from 30 secs to 60 secs helped, the page appears after around 30 secs."

(If the outgoing http request timeout is 30 secs then this would make sense)

After some digging around, I found my problem was my work's proxy server blocking certain modules which need make http requests. One of those modules is Update Status, a contributed Drupal 5 module which is now part of core in Drupal 6.

I did try the tips mentioned above first: Using 127.0.0.1 instead of localhost made no difference on my PC, but commenting out the "::1" line in the hosts file improved things and got rid of the "HTTP request status Fails" message in the status report. At least it was working, but it was still too slow to use for serious development work.

So I ditched Xampp altogether and tried WampServer. However, after reading this thread, this time when installing Drupal, I unchecked "Check for updates automatically". Presto, it worked beautifully. Just to be sure, I enabled the Update Status module, and the result was worse than Xampp's. All admin pages just went blank with WampServer. So after a quick reinstall, again disabling the Update Status module, and I was up and running nicely again. (I didn't bother trying this on Xampp, but I'd be surprised if didn't work).

Then I tried bypassing the proxy server (don't ask) and enabling the Update Status module. Presto, it worked beautifully again.

So, as I see it, here are the options for those with the same problem as me:

1. If you don't use other modules, (eg Aggregrator) which make HTTP requests, you could do without the Update Status module for your test setup and make manual updates instead.

2. Read through this lengthy thread about adding support for intranet sites behind proxy servers, and apply the relevant patch. (I haven't bothered trying).

3. Set up your test/development site online.

4. Bypass the proxy somehow. If that's not possible, it could be a good excuse to work from home. . . or

5. Unplug the network cable, and forget about the outside world :-)

Re: #11 - I don't think it's XAMPP, because I am running XAMPP Lite here today (teaching Drupal) and Update Status doesn't work, but it is fine running XAMPP Lite at the company I'm contracting for. Proxy settings are definitely a possibility. What port does Update Status try to use though? Proxies shouldn't normally interfere with normal Internet traffic, and access to Drupal.org via a web browser is unimpeded.

Both machines (working and otherwise) are Windows XP, latest XAMPP Lite but behind different corporate networks.