2

Do you usually use vagrant for magento? Our live sites are very fast but only because of varnish. We reach under 1 sec load time. However on vagrant it takes ~30 seconds for a page load. With Mamp it takes ~10 seconds.

I've checked the settings, there is no difference between mamp and vagrant instances. Having varnish in developing mode quite pointless, so how do people manage to use vagrant with magento?

Thanks!

  • 1
    Make sure xdebug or similar isn't running all the time. It will slow everything down. Also, you better use an SSD when developing locally. Even the 10 sec load time is not really workable imo. – Milan Simek Oct 19 '15 at 17:40
  • Our live sites are very fast but only because of varnish. Sigh. – Ben Lessani - Sonassi Oct 19 '15 at 20:53
  • @BenLessani-Sonassi Would be better as an advice – Claudiu Creanga Oct 19 '15 at 22:54
3

Try increasing the memory and CPU cores on your Vagrantfile. I came across this post and that's how I setup mine.

https://stefanwrobel.com/how-to-make-vagrant-performance-not-suck

I use all CPU cores and 1/4 of my system's memory (4096).

I'm not sure if you'll get the same performance as your live server, but it might help improve the performance on your local environment.

  • I have found that I can get away with 512mb of ram and 1cpu when I use Redis caching. – Joseph at SwiftOtter Oct 19 '15 at 17:16
3

If you are using Vagrant during Magento development, Magento may work slowly on Vagrant because of the type of synched folders. In case when your Magento codebase is located on the host and mounted by the guest, while processing requests, Magento will read source files via network from the host. If this network connection is slow request processing will take ~30 seconds or even more. See more detailed explanation.

If you host is Mac or *nix, just make sure to use NFS for shared folders.

For Windows hosts, there is no performant solution provided by Vagrant. However you may consider using Vagrant configuration, which minimizes reads from the host during request processing and thus can be used with any sync folder type (even default, Virtual Box shared folders).

  • What about developing directly on VM and viewing the website in Windows? Whould it be a good alternative? – Alan Dec 2 '17 at 19:08
  • 1
    @Alan I know some developers using such setup. So this should work considering that your computer is powerful enough to handle VM with installed IDE seamlessly. There could also be issues with hotkeys usage on the VM – Alex Paliarush Dec 5 '17 at 23:34
  • thanks, I tested it last weekend and, as you write, it consumes a lot of CPU and of RAM. The biggest problem is though that Magento is still very slow, while synced folders are off. I have 2 installs: fresh and a webshop cloned from another server(where it runs ok) - both are affected. I was using Ubuntu, PHP7.0, intel i5, 6GB RAM(on vm), SSD. I'll try to use profiler although I'm not sure if it'll work - pages load >1min, CPU use is high. Do you have any suggestions how I could debug this(environment or magento-wise)? – Alan Dec 6 '17 at 17:25
  • Make sure to enable all caches, they must be enabled during development (even in developer mode). And clear them only when necessary. It is also possible to clear specific cache type only, this article should be helpful. – Alex Paliarush Dec 7 '17 at 15:27
1

I made this vagrant which allow you to customize mount options and has great performance:

  • nfs mount or regular mount
  • directory mount /var/www/magento/app or whole project /var/www/magento

https://github.com/zepgram/magento2-fast-vm

You can work on a fast magento installation and adapt parameters depending on your work practice and your host machine perf.

For example, if your host machine doesn't support NFS option and has bad performance you can mount only app directory which is enough for development.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.