Extremely slow page loads

[tmlangley]

On all of my vlad sites, I'm experiencing page load times up to 35 seconds even on a fresh Drupal install (Profiler screen cap below). About half of the developers on my team are experiencing this issue and we're all using very similar Macs. Ping response on the site is normal, and running wrk benchmarking yields pretty standard results.

Useful info/things we've tried:

• NFS is enabled
• We tried setting localhost to 127.0.0.1 in settings.php because we've had issues with that before
• We tried removing drupal.local in hosts file since the .local extension is a known performance hit in newer osx versions. Not sure why this would matter if we aren't going to that url though
• Increased number of cpus and memory

I'm happy to provide more information, but it's hard to know what is relevant at this point.

[tmlangley]

After a whole day of debugging this I found the issue was my debugger! Apparently, if you turn on xdebug in one tab and forget to turn it off, your site performance will suffer significantly. My IDE was no longer listening or had any breakpoints so obviously it was never stopping the execution. What I don't understand is why completely destroying and re-provisioning my box did not fix the issue. I intend to look into this more but since I did get it working I'll go ahead and close the issue.

[philipnorton42]

Hey @tandroid1, Thanks for raising (and subsequently closing) this issue :) We have received a few reports of extremely slow page loads and not found out what is wrong. I'd be interested to know what IDE are you using as this might trip other people up in the future. Perhaps there is something we can set (or unset) to prevent this.

[tmlangley]

Hey @philipnorton42,

Sorry for closing the issue so soon. I'm using PHPStorm, but it shouldn't be IDE specific since the variable generally gets set on the browser side. I'm using bookmarklets generated from this online tool to enable/disable step debugging. All this really does is set the _COOKIE["XDEBUG_SESSION"] variable. Since this is a cookie that is set globally for all sites, it makes sense why you could turn on xdebug for one site, and see slow page loads on another.

The strange part in all of this is why some sites and users seem to suffer from it much worse than others. For instance, when testing, I had xdebug turned on and was seeing very slow page loads on one site but not on another vlad site with nearly identical configuration. I also never experienced issues when I was using MAMP. This makes me think that there is something that could be done with vlad to fix the issue.

[twerthmueller]

I can confirm, that we also have extremely slow page loads after debugging (not always). Also when I stop the debugging in the browser or I access the page with a different browser. A restart of the apache on the box resolves the problem (destroys hanging debug sessions?).

[christopher-hopper]

See issue #350 as related to performance. I found after fixing the CPUs allocated, I got better performance.

Other performance problems though I've been looking at:

• File system operations are extremely slow in the site docroot.
• File ownership and group is reported by uid and gid because the host user and group are not created on the guest.

I think the file sharing in the Vagrantfile might need to be looked at. It seems to be causing Drush commands to run extremely slowly. I can only assume at this point it also slows the Apache web server.

I'm using a Linux host, with a Centos guest. NFS shares are created but performance on other non-Vlad VirtualBox instances I have is much better than in Vlad.

[philipnorton42]

Thanks for following this up Chris. Since version 1.1.7 came out we are looking to overhaul the system as much as possible into a newer version 2.0. So now is a good time to revisit all this stuff.

Vlad actually creates two shared folders. One for the docroot and one for the vlad_aux directory. Here is the relevant config from the Vagrantfile:

# Setup synced folder for site files
config.vm.synced_folder vconfig['host_synced_folder'], "/var/www/site/docroot", type: "nfs", nfs_udp: false, create: true, id: "vagrant-webroot"

# Setup auxiliary synced folder
config.vm.synced_folder vconfig['aux_synced_folder'], "/var/www/site/vlad_aux", type: "nfs", nfs_udp: false, create: true, id: "vagrant-aux"

I'm starting to think that both folders might not be needed, especially as Vagrant creates it's own mounted drive under /vagrant. This share contains the whole project so it might be better to symlink from there to create the same structure internally. I'm not sure if creating multiple NFS shares is causing this slowdown, but it might be worth some investigation?