在 Vagrant 开发网站上加载页面之前的大量空闲时间
Massive idle time before loading a page on Vagrant development site
仅包含一些 PHP 代码的文件运行良好且速度快,对于包含 MySQL 连接查询的文件也是如此。据我所知,一切似乎都运行良好,但尝试在 Magento 中加载任何页面时除外。第一次加载需要 60 多秒,然后 Magento 缓存启动,后续加载超过 20 秒,但关键问题仍然是事情开始之前的大量空闲期。
这不可能是因为 VM 同步功能,因为在这种情况下 none 的网站文件位于同步文件夹中。我已经构建了脚本来提取和安装特定目录以进行处理,因此只需要同步少量文件而不是整个网站。
我已经尽我所能搜索、研究并尝试了所有可能的方法,但我仍在寻找解决方法。
如果有任何有助于找到解决方案的日志,请告诉我在哪里可以找到它们。
使用:
- Vagrant 1.8.4
- 虚拟盒子 5.0.24
- CentOS 6.8
- Apache/2.2.15
- PHP 5.5.38
- MySQL 14.14
- Magento CE 1.9.2.3
由于一些 SSH 错误,不得不使用较旧的 Vagrant 版本,反过来我也不得不使用较旧的 VirtualBox。
Vagrantfile:
Vagrant.configure("2") do |config|
config.vm.box = "package.box"
config.vm.network "private_network", ip: "192.168.3.4"
config.ssh.insert_key = false
# The code below sets the VM memory to half of the host's and number of CPU cores to 4
# None of the variations of those VM settings that I have tried affect the idle time when trying to load the site
config.vm.provider "virtualbox" do |v|
host = RbConfig::CONFIG['host_os']
# Give VM 1/4 system memory
if host =~ /darwin/
# sysctl returns Bytes and we need to convert to MB
mem = `sysctl -n hw.memsize`.to_i / 1024
elsif host =~ /linux/
# meminfo shows KB and we need to convert to MB
mem = `grep 'MemTotal' /proc/meminfo | sed -e 's/MemTotal://' -e 's/ kB//'`.to_i
elsif host =~ /mswin|mingw|cygwin/
# Windows code via https://github.com/rdsubhas/vagrant-faster
mem = `wmic computersystem Get TotalPhysicalMemory`.split[1].to_i / 1024
end
mem = mem / 1024 / 2
v.customize ["modifyvm", :id, "--memory", mem]
v.cpus = 4
end
config.vm.provision :shell, path: "resources/bootstrap.sh"
config.vm.provision :shell,
inline: "service httpd start; mount -a -o nonempty",
run: "always"
# Run these provisioners when needed with $vagrant provision --provision-with name
if ARGV.include? '--provision-with'
config.vm.provision "site", type: :shell, :inline => "source /vagrant/resources/build_site.sh"
end
end
我用了kaorimatz/centos-6.8-x86_64 base box,设置了LAMP stack,进一步配置机器,打包成这个base box。
PHP memory_limit 好像也不影响空闲时间。
页面加载统计截图:
- "Page load time" Chrome 分机
Page load time extension
- Chrome 开发者工具时间表
Developer Tools Timeline
顶部时间轴上的页面快照必须是之前的加载,因为在空闲期结束之前什么都没有发生,之后当前页面重新加载并且 DOM 在合理的时间内再次构建。
在时间轴中似乎有那些微小的功能(一开始是一串条纹,然后间隔开直到大加载周期发生)。
Timeline开头的前6行是每行重复的函数:
第 1 行:计时器已触发
第 2 行:函数调用
第 3 行:(匿名函数)
第 4 行:C
第 5 行:设置超时
第 6 行:安装计时器
很难确定这是否是您遇到的问题,但我最近一直在进行与您类似的设置,发现将 Vagrantfile 中的 v.cpus = 4
更改为 v.cpus = 1
大大改进了 Magento 页面加载时间。你可能认为更多 cpu 个内核会更快,但事实证明 Virtualbox 并不擅长并行处理,如这里详细解释的那样:
http://www.mihaimatei.com/virtualbox-performance-issues-multiple-cpu-cores/
这里:
https://ruin.io/2014/benchmarking-virtualbox-multiple-core-performance/
这里:
https://forums.virtualbox.org/viewtopic.php?f=3&t=64268
这里:
https://github.com/roots/trellis/issues/410
问题的核心是具有多个 vCPU 的 Virtualbox VM 要求所有分配的内核在主机上空闲,然后才能开始处理。因此,对于 4 个虚拟 cpus,每次 Virtualbox 在主机上安排 cpu 时间时,它都会等到所有 4 个内核都可用。在页面加载过程中,这段等待时间显然会增加很多。
无论如何尝试减少虚拟 cpu 的数量。希望它对你有所作为。
我自己解决了这个问题,尽管是在围绕实际解决方案循环一周之后。感谢所有尝试提供帮助的人。
对于任何在任何地方构建繁重的开发站点系统(包括虚拟机)的人 - 我犯了一个错误,一开始只是轻描淡写地忽略了我将 Magento 的核心 PHP 文件安装在 SSHFS 上以节省存储和复制时间。 SSHFS 仍然非常适合大型媒体文件夹和不太密集的 Magento PHP 文件目录,但是 Magento 的文件数量 运行 从 index.php 到构建的 DOM真是疯了。
仅包含一些 PHP 代码的文件运行良好且速度快,对于包含 MySQL 连接查询的文件也是如此。据我所知,一切似乎都运行良好,但尝试在 Magento 中加载任何页面时除外。第一次加载需要 60 多秒,然后 Magento 缓存启动,后续加载超过 20 秒,但关键问题仍然是事情开始之前的大量空闲期。
这不可能是因为 VM 同步功能,因为在这种情况下 none 的网站文件位于同步文件夹中。我已经构建了脚本来提取和安装特定目录以进行处理,因此只需要同步少量文件而不是整个网站。
我已经尽我所能搜索、研究并尝试了所有可能的方法,但我仍在寻找解决方法。 如果有任何有助于找到解决方案的日志,请告诉我在哪里可以找到它们。
使用:
- Vagrant 1.8.4
- 虚拟盒子 5.0.24
- CentOS 6.8
- Apache/2.2.15
- PHP 5.5.38
- MySQL 14.14
- Magento CE 1.9.2.3
由于一些 SSH 错误,不得不使用较旧的 Vagrant 版本,反过来我也不得不使用较旧的 VirtualBox。
Vagrantfile:
Vagrant.configure("2") do |config|
config.vm.box = "package.box"
config.vm.network "private_network", ip: "192.168.3.4"
config.ssh.insert_key = false
# The code below sets the VM memory to half of the host's and number of CPU cores to 4
# None of the variations of those VM settings that I have tried affect the idle time when trying to load the site
config.vm.provider "virtualbox" do |v|
host = RbConfig::CONFIG['host_os']
# Give VM 1/4 system memory
if host =~ /darwin/
# sysctl returns Bytes and we need to convert to MB
mem = `sysctl -n hw.memsize`.to_i / 1024
elsif host =~ /linux/
# meminfo shows KB and we need to convert to MB
mem = `grep 'MemTotal' /proc/meminfo | sed -e 's/MemTotal://' -e 's/ kB//'`.to_i
elsif host =~ /mswin|mingw|cygwin/
# Windows code via https://github.com/rdsubhas/vagrant-faster
mem = `wmic computersystem Get TotalPhysicalMemory`.split[1].to_i / 1024
end
mem = mem / 1024 / 2
v.customize ["modifyvm", :id, "--memory", mem]
v.cpus = 4
end
config.vm.provision :shell, path: "resources/bootstrap.sh"
config.vm.provision :shell,
inline: "service httpd start; mount -a -o nonempty",
run: "always"
# Run these provisioners when needed with $vagrant provision --provision-with name
if ARGV.include? '--provision-with'
config.vm.provision "site", type: :shell, :inline => "source /vagrant/resources/build_site.sh"
end
end
我用了kaorimatz/centos-6.8-x86_64 base box,设置了LAMP stack,进一步配置机器,打包成这个base box。
PHP memory_limit 好像也不影响空闲时间。
页面加载统计截图:
- "Page load time" Chrome 分机 Page load time extension
- Chrome 开发者工具时间表 Developer Tools Timeline 顶部时间轴上的页面快照必须是之前的加载,因为在空闲期结束之前什么都没有发生,之后当前页面重新加载并且 DOM 在合理的时间内再次构建。
在时间轴中似乎有那些微小的功能(一开始是一串条纹,然后间隔开直到大加载周期发生)。 Timeline开头的前6行是每行重复的函数:
第 1 行:计时器已触发
第 2 行:函数调用
第 3 行:(匿名函数)
第 4 行:C
第 5 行:设置超时
第 6 行:安装计时器
很难确定这是否是您遇到的问题,但我最近一直在进行与您类似的设置,发现将 Vagrantfile 中的 v.cpus = 4
更改为 v.cpus = 1
大大改进了 Magento 页面加载时间。你可能认为更多 cpu 个内核会更快,但事实证明 Virtualbox 并不擅长并行处理,如这里详细解释的那样:
http://www.mihaimatei.com/virtualbox-performance-issues-multiple-cpu-cores/
这里: https://ruin.io/2014/benchmarking-virtualbox-multiple-core-performance/
这里: https://forums.virtualbox.org/viewtopic.php?f=3&t=64268
这里: https://github.com/roots/trellis/issues/410
问题的核心是具有多个 vCPU 的 Virtualbox VM 要求所有分配的内核在主机上空闲,然后才能开始处理。因此,对于 4 个虚拟 cpus,每次 Virtualbox 在主机上安排 cpu 时间时,它都会等到所有 4 个内核都可用。在页面加载过程中,这段等待时间显然会增加很多。
无论如何尝试减少虚拟 cpu 的数量。希望它对你有所作为。
我自己解决了这个问题,尽管是在围绕实际解决方案循环一周之后。感谢所有尝试提供帮助的人。
对于任何在任何地方构建繁重的开发站点系统(包括虚拟机)的人 - 我犯了一个错误,一开始只是轻描淡写地忽略了我将 Magento 的核心 PHP 文件安装在 SSHFS 上以节省存储和复制时间。 SSHFS 仍然非常适合大型媒体文件夹和不太密集的 Magento PHP 文件目录,但是 Magento 的文件数量 运行 从 index.php 到构建的 DOM真是疯了。