Development mode super slow


(Bill Dudney) #1

I’ve gotten vagrant up and running with a development environment but it’s taking forever to load.

For example http://192.168.10.200:3000/ takes tens of seconds to load.

I’m running the whole stack on a new rMBP with OS X 10.8.2.

Any ideas of what I’ve done wrong? Or is this just a function of being on the bleeding edge?

Thanks,

-bd


HOWTO Develop In A Windows Environment Using Vagrant
(Dan Neumann) #2

I came across someone else lamenting the same issue.

They resolved it by just running it on OSX rather than within the VM. Sounds like an idiosyncrasy with something in the VM.

Similarly, I just run it on my Macbook Air without a VM and it’s quick.


(Dan Neumann) #3

My local stack on OSX:

  • Postgres installed with Heroku’s Postgres.app. Even more convenient than Homebrew’s postgres. You just launch the app when you want Postgres to be running. Just note that you need to specify localhost when using psql (psql -h localhost) and you need a line host: localhost in database.yml (Discourse already has that, though. But it’s good to know for other Rails apps you may work on).
  • Ruby 1.9.3 with RVM.
  • Redis with $ brew install redis and run in its own terminal tab: $ redis-server.

(Ted Lilley) #4

I might check with top or htop how the vm is performing from the inside. Does it have enough memory? Is it CPU-bound?


(Bill Dudney) #5

Bumped the VM to 2GB to test, still takes tens of seconds. Its CPU bound according to htop.


(Ted Lilley) #6

Halt the vm, go into the virtualbox gui and see if you can match the number of cpus to the actual number of cores in your machine.

Also see if virtualbox is reporting that hardware virtualization support is enabled.

Edit: Duh, I forgot my best performance tip, and this is likely the biggest cause.

Shared folders are really slow. This is bad for Rails apps.

Try just copying everything from /vagrant into a local folder (I use ~/vagrant), then running it again.

For my development, I keep two aliases in my .zshrc:

alias sin="rsync -a --delete /vagrant ~"
alias sout="rsync -a --delete ~/vagrant /"

These will nuke files if you’re not careful with the direction you’re going. “sin” is “sync in” to the vm and you can guess what “sout” stands for.

I haven’t tried this with Discourse, but it’s a necessary evil for my other Rails projects.

I’m on Windows, so there’s another trick that doesn’t help me but might help you; you can use NFS instead of VB shared folders to get at the files, which is performant and gets rid of the syncing issues. You’ll have to google it, I forget where I saw it.


(SituationSoap) #7

I noticed that things were slow last night when I set up my own install outside the VM, but just for the first request or two. After that, they were slower than this site, but not overwhelmingly slow, perhaps 200ms per response, part of which might be due to event machine not being set up on my computer and erroring on every request.


(Bill Dudney) #8

Thanks for your help in nailing this down!

I upped the # of CPU’s to 8 but then it complained that non-optimal settings were detected. I backed down to 2. The physial CPU has 4 cores, 8 virtual cores.

I don’t see where ‘hardware virtualization’ is, sorry I’ve not looked at Virtual Box in years.


(Bill Dudney) #9

I just timed it again, 90 seconds from hitting the reload button to getting the page rendered.

htop reports between 30 and 70% CPU usage and a very small part of the 2GB used.

Thanks again.


(Ted Lilley) #10

No problem. See my edits above for another idea.

For the hardware support, it’s under the System > Acceleration tab. If it lets you do multiple CPUs, I think acceleration is required, so you’ve probably got it.

It’s also shown by the little cpu icon in the lower right-hand corner of the console window, but since you don’t use that when you’re using vagrant, you probably won’t have cause to see that.

Last tip: I share the same project files between multiple machines with Dropbox. You have to vagrant up a new vm on each machine, but you can get them to coexist with the same project files if you match the virtual machine hardware ids in your various environments. I wrote a post about it if anyone’s interested.


(Ted Lilley) #11

The CPU slider in the gui should have a green bar that tells you how far you can correctly go on your current hardware. FYI.


(Bill Dudney) #12

NFS made a huge different, down to 6 or 7 seconds from 90. Thanks!

For those coming after me, in the Vagrantfile update this line:

config.vm.share_folder("v-root", "/vagrant", ".")

to this:

config.vm.share_folder("v-root", "/vagrant", ".", :nfs => true)

Still slow but not unreasonably slow.

I tried to get things up and running out of the VM and ran into other troubles. I’ll post a ‘Reply as new Topic’ response with details.


(Ted Lilley) #13

Running Rails in development mode on a vm is always going to come at a penalty, so 6 or 7 seconds probably isn’t too bad. Every time it services a request it has to scan all of the source files for changes, since that’s how it keeps you from having to restart the server every time you edit code. All of the native Rails caching is off in development mode as well. On top of all that, you’ve got the virtualization tax. So yeah, it’ll feel slower than production, that’s for sure.

Glad I could help.


(James) #14

I’ve completed all the steps from DEVELOPMENT.md but Discourse is painfully slow! Upped the VM’s CPU and Memory but it’s still not usable. I’m completely new to Rails and Vagrant which isn’t helping to be honest!

Could you please elaborate on your suggestion of getting rid of the shared folders? I see that my discourse folder is shared, along with the vagrant folder that gets shared during VM startup.


(Ted Lilley) #15

[quote=“bdudney, post:12, topic:2179”]NFS made a huge different, down to 6 or 7 seconds from 90. Thanks!

For those coming after me, in the Vagrantfile update this line:

config.vm.share_folder(“v-root”, “/vagrant”, “.”)
to this:

config.vm.share_folder(“v-root”, “/vagrant”, “.”, :nfs => true)[/quote]

That’s your best bet. I don’t run Mac, so I can’t help you more. Google for “virtualbox shared folders nfs” if you need help.


(Rebecca Chernoff) #16

90 seconds is “nothing”. On a Windows host with the Vagrant box, I’m seeing 4-6 minutes.


(James) #17

Unfortunately I’m running windows too.


(Bill Dudney) #18

wow, minutes is crazy slow. @binaryphile seems to have vagrant figured out on windows. I’d say go read his previous posts.

Or of course you and @shrimpeh could just go pick up a Mac :smiley:

Good luck!


(Ted Lilley) #19

Your best bet is to use the “sin” and “sout” aliases I described above. They use the rsync command (think xcopy, but set so it doesn’t copy older files over newer ones). Stick those lines in .bashrc in the vm, then source .bashrc to make it active. You’ll only need to do that once, they’ll get loaded automatically after that.

The shared folder is /vagrant when you’re at the vm command line. sin will copy everything from there to your home directory, so everything ends up in ~/vagrant (note the tilde).

cd to ~/vagrant and run the app. It will be 10x faster than trying to run it from the /vagrant shared folder.

When I’m done, I use sout to copy everything back out to my windows machine to keep it safe, so you don’t nuke it accidentally by destroying the vm or something. I also do this in Dropbox, so the sout makes my changes available to all of my other computers as well.

Good luck.


(sirtimbly) #20

Just to confirm: I had the same issue using Vagrant and Virtualbox on a 2 year old MBP, with initial requests taking more than one minute. I changed the Vagrantfile to use NFS and upped my VirtualBox machine config to use 2 cores. Response times are now within my expectations.