Symfony2 应用程序在 VirtualBox 中非常慢
我在 VirtualBox 上运行 Debian 的虚拟副本，以在 nginx/php5-fpm/MySQL 堆栈上开发更大尺寸的 PHP 应用程序。开发发生在主机操作系统 (Windows 7 x64) 中，代码作为共享文件夹安装在来宾操作系统中。
性能很差。以下是本机 vbox 文件系统和使用 cifs 的 samba 挂载的 webgrind 输出：
无论哪种情况，filemtime、file_exists 和 is_read 需要几秒钟才能运行。 CPU负载非常高，内存使用似乎正常。
这三个函数的输出不是都缓存在统计缓存中吗？他们为什么要花这么长时间？
我真的很感激我能得到的任何帮助！
编辑：澄清一下，生产性能很好。在我们的（正确的、非虚拟的）登台服务器上，PHP 代码在生产设置中的执行时间最长约为 60 毫秒，在开发模式下的执行时间在 100-200 毫秒之间。
我需要帮助弄清楚为什么 VirtualBox 在开发和运行中慢 100 倍。产品模式。
我刚刚检查过，生产设置的执行速度约为 5 秒。仍然无法使用，而且开发起来也很尴尬。
I run a virtual copy of Debian on VirtualBox to develop a larger-sized PHP application on a nginx/php5-fpm/MySQL stack. Development happens in the host OS (Windows 7 x64), the code is mounted as a shared folder in the guest OS.
Performance is very bad. The following are webgrind outputs for the native vbox filesystem and a samba mount with cifs:
In either case filemtime, file_exists and is_readable take several seconds to run. CPU load is very high, memory usage seems normal.
Isn't the output of all three of these functions cached in the stat cache? Why are they taking so long?
I'd really appreciate any help I can get!
Edit: To clarify, production performance is fine. On our (proper, non-virtual) staging server the PHP code executes in ~60ms max in production settings and somewhere between 100-200ms in dev mode.
I need help figuring out why VirtualBox is 100x slower in dev & prod mode.
I just checked, production settings yield ~5sec execution. Still unusable, plus it's awkward to develop with.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
使用nfs文件共享。 Samba 和 vbox 文件共享可能非常慢。
您的分析表明文件系统操作是瓶颈。
阅读这篇博文 http://clock.co.uk/tech -blogs/virtualbox-404-shared-folder-update 了解更多信息
Use nfs file sharing. Samba and the vbox file share can be very slow.
Your profiling indicates that file system operations are the bottleneck.
Read this blog post http://clock.co.uk/tech-blogs/virtualbox-404-shared-folder-update for more insight
我最近回答了类似的问题。您可以在此处找到我之前的答案。
我会写一份小简历。您不应仅根据
app_dev.php前端控制器来衡量应用程序的性能。该控制器的创建仅供开发使用。在开发过程中，您会对配置文件、树枝模板、资源等进行大量更改。Symfony 将检查数百个文件是否有修改，并在必要时重新加载大量以前缓存的内容，因此会大量调用filemtime、<代码>file_exists和<代码>is_可读。所有这些调用在生产模式下都会被绕过，因为 Symfony 期望缓存中的所有内容都是最新的。因此，几乎所有可能的东西都会在生产模式下缓存并立即使用，而无需 Symfony 检查文件是否已被修改。这带来了巨大的性能提升，因为在开发中重新加载单个文件可能需要花费很多时间来解析它、检查它的依赖关系、重新缓存依赖于该文件的所有内容等等。如果您正在对应用程序进行基准测试，请像在生产模式下一样对其进行基准测试。至少，如果您在生产中无法按照预期进行所有硬件设置，请执行以下步骤。清除生产模式的缓存并使用
app.php而不是app_dev.php。另外，请查看有关 性能 的部分，该部分可在 symfony.com 上找到文档。这里控制台调用以清除并预热生产环境中的缓存。我认为cache:clear也会预热缓存，但由于我不是 100% 确定，我更喜欢同时进行这两个调用：希望这会有所帮助。
问候，
马特
I recently answered a similar question. You can find my previous answer here.
I will make a small resume of it. You should not measure performance of your application based solely on the
app_dev.phpfront controller. This controller has been created to be used for development only. In development, you make lots of changes to configuration files, twig templates, assets, etc. Symfony will check hundred of files for modifications and reload a lot of previously cached stuff if necessary hence the high number of calls tofilemtime,file_existsandis_readable. All this calls are bypassed in production mode because Symfony expect everything in the cache to be up-to-date. So, almost everything possible is cached in production mode and used right ahead without Symfony checking if the file has been modified or not. This gives a huge performance boost because reloading a single files in development can take a lot of times to parse it, check dependencies on it, recache everything depending on this files and so on.If you'are benchmarking your application, benchmark it as if it was in production mode. At least, if you can't have all the hardware setup as you expect it in production, do the following steps. Clear your cache for production mode and use
app.phpinstead ofapp_dev.php. Also, check the section on performance that can be found on symfony.com in the documentation. Here the console calls to clear and warmup your cache in production environment. I thinkcache:clearwill also warmup the cache, but since I'm not 100% sure, I prefer to make both calls:Hope this helps.
Regards,
Matt
只是为了将其联系起来：
最后，我在来宾操作系统上设置了 samba 共享，将其绑定到第二个网络适配器（仅主机，如本指南中）并将其作为网络驱动器安装在主机操作系统中。
有点 hacky，但在带有分析的开发模式下，执行时间从 5-13 秒减少到 100-500 毫秒。
Just to tie this up:
In the end I set up a samba share on the guest OS, bound it to a second network adapter (host-only, like in this guide) and mounted that as a network drive in the host OS.
A little hacky, but execution times are down to 100-500ms from 5-13sec in dev mode with profiling.
除了
Matt所说的之外，我建议您编译 twig 扩展并将其用作 php 模块。它将更快地生成模板。但最重要的是在产品环境中运行应用程序进行任何基准测试，而不是在开发或测试中。确保不在生产环境中加载 xdebug 模块，因为它也会降低基准测试速度。我不知道您的确切设置，但如果您安装正确的反向代理（又名 Varnish）而不是
AppCache以尽可能少地向应用程序本身发出请求，您很可能会获得更好的结果。In addition to what
Mattsaid I recommend you to compile twig extension and use it as php module. It will generate templates faster. But still the most important is to do any benchmarks running your app in prod environment, but not in dev or test. Make sure you don't load xdebug module in production, because it will slow down your benchmarks as well.I don't know your exact settings, but most-likely you will have better results if you install proper reverse proxy (aka Varnish) instead of
AppCacheto make as little requests to app itself as possible.遇到了同样的问题，通过设置 rsync cron 来修复它，使虚拟机和主机上的代码保持同步。
显然，Virtualbox 共享文件夹在文件读取/写入方面非常慢：/
如果您有兴趣，请在博客中详细介绍我的解决方案
Had the same issue, fixed it by setting up a rsync cron that keeps the code on the VM and the host in sync.
Apparently Virtualbox shared folders are pretty slow when it comes to file reading/writing :/
Blogged about my solution in detail if you are interested