Homestead TTFB > 2sec issue .. Help

My TTFB is 884 ms. Windows 8, HDD, 4GB of Ram and my homestead machine in this computer has 512 mb of ram.

Only thing I can think of off the top of my head is to make sure the VirtualBox Guest Addition version matches the VirtualBox version. If you are running VirtualBox 5, you probably need to update the guest addition in Homestead.

@mikebronner I am running Virtualbox 4.3.30

Does it do it on any VM? Could be a DNS lookup or something. You just testing it on Chrome network tab?

Mac Mini with Vaprobash on, connected to work router and visiting via LAN (150ms~ TTFB)

@bashy

I have tried deleting the VM and creating a new one .. still the same. I have tried accessing other Laravel projects on that VM .. still the same. I've only tested it in Chrome.

Screenshot

Could it be a DNS issue? My host DNS is setup to use Google 8.8.8.8 and 8.8.4.4.

VM has an IP of 192.168.10.10 and my virtualbox adapter is on 192.168.10.1.

I feel like waiting for air to pass the street..

TTFB here was 217ms and that was with Laravel Debugbar.

Update: With APP_DEBUG=false in .env, I've got ~ 140ms.

• VirtualBox 5.0.2
• Vagrant 1.7.4
• laravel/homestead (virtualbox, 0.2.7) (configured to use NFS between VM and host filesystem)

Relevant homestead config portion:

folders:
    - map: ~/src
      to: /home/vagrant/src
      type: nfs

Mac OS X Yosemite 10.10.5, notebook's i7, 8GB, SSD.

I would confirm it's not just Homestead. Try Vaprobash? Could be some weird setting that's causing it.

@bashy I've just tried with Vaprobash and on a fresh laravel install I get 543ms

That is much better than 1.5s but still it seems high

I did traceroute and pinging the ips and always I get <1ms or less.

I have tried running the app with blackfire and it reports that @compiled_files takes 480ms.

I don't know where to look next..

@mabasic :

replace DB_HOST=localhost to DB_HOST=127.0.0.1 and try again

@jabba I tried using localhost, 127.0.0.1 and 192.168.10.10 , but I still get the same result.

My TTFB now is from 335ms ~ 2.5s

If it does not hit the database it can get as low as 335ms. If it hits the database then it's around 1.16s. If I enable debugbar it goes to 2.0s ~ 2.5s.

This is my setup atm:

• Windows 10 x64bit
• Virtualbox 4.3.30
• Vagrant 1.7.4
• Homestead 2.1.7
• Homestead box 0.2.7

Homestead is running on 3 CPUs, 2048 MB RAM, SSD, IP: 192.168.10.10

My virtualbox adapter is on 192.168.10.1/255.255.255.0

You must have something waiting. Example waiting time for DNS resolve. I've never had an issue with it being higher than 200ms. My VM at work has a 400ms TTFB even from outside the LAN.

Also try Clockwork for Chrome: https://chrome.google.com/webstore/detail/clockwork/dmggabnehkmmfmdffgajcflpdjlnoemp

I have debug bar installed and I checked timeline, it says:

Booting (1.47s)

Application (456.78ms)

After application (72.39ms)

This is weird: If I refresh the page and then stop it and then quickly start the refresh again I get much lower TTFB (720ms) usually ~2.0s

If I run php artisan serve from my host and visit http://localhost:8000 it has TTFB ~300ms. This feels fast already

Now debugbar reports:

Booting (333.42ms)

Application (77.17ms)

After application (19.77ms)

Why is booting taking so long?

I don't use Homestead, but relatively complex CRUD application on my Win7 laptop, i5-3230 @ 2.6 GHz with SSD and 6GB RAM, takes no more than 150ms.

Another app with only a few controllers takes also 150ms to generate default Laravel 5 page.

A few months ago, i got similar problem, which was related to MySQL connection. Every operation which takes data from MySQL took 3-5 seconds. Solution was to change DB_HOST from DNS name to IP address.

Your problem is probably related to some of the following:

• Apache or php.ini settings (there is a lots of tuning tips on Google, try to increase workers and similar stuff)
• Disk IO (try to monitor it with iotop - http://www.cyberciti.biz/hardware/linux-iotop-simple-top-like-io-monitor/)
• Swap and RAM usage on Homestead ( http://www.cyberciti.biz/faq/linux-check-memory-usage/)

I also remember reading (forgot where) that the recommended minimum for Laravel/PHP is 1GB of RAM. Have you tried upping your VM memory?

@mikebronner Stated a few replies down that they tried with 2GB RAM

Homestead is running on 3 CPUs, 2048 MB RAM, SSD, IP: 192.168.10.10

If you ssh into your homestead VM and try accessing the site with cURL, does that improve things?

time curl -H "Host: myapp.dev" http://localhost

That would be the same as http://myapp.dev, but you probably don't have the hosts file adjusted for that -inside- your VM, so above fixes that by setting the Host header manually.

@mabasic Have you got NFS enabled? I found that by enabling this it increased the TTFB considerably.

I'm also on a Windows box, and getting NFS working can be a real pain. Switching to VMware Workstation made it much more reliable, but at a cost :-/

@Shovels NFS is not supported on Windows.

Windows users: NFS folders do not work on Windows hosts. Vagrant will ignore your request for NFS synced folders on Windows.- Vagrant documentation

I considered switching to VMware Woekstation but it costs so damn much.

@jabba I have tried using top and free -m to check CPU and RAM usage. When the page refreshes CPU usage goes to almost 25% and RAM is steady at 900mb / 2048. isotop seems normal.

@layer7 After using that command I get:

real    0m1.347s
user    0m0.007s
sys     0m0.011s

@mabasic If I/O is your bottleneck, you would see %wa going up considerably in "top" during your calls. You could basically ram the F5 key in order to get a continuous stream of requests, or use a benchmarking tool like "ab" (ApacheBench, but it's not limited to Apache)

@layer7 I have tried pressing F5 non stop and checking top command. wa is always 0.0

But php5-fpm spawns 5 processes and each of them consumes 40% cpu.

I have also noticed that when pressing F5 more than 10 times my TTFB varies between 150ms and 2.0s

Ideally you would be able to test the codebase when it's not running through Virtualbox shared folders to confirm whether that's the issue or not. Just copy the code inside the VM to another folder and adjust the paths in /etc/nginx/sites-enabled/yoursite (and restart nginx after).

If you can confirm that vboxsf is the bottleneck, you could try this: http://www.virtualbox.org/manual/ch12.html#idp46856138635264

Or you could try this if vboxsf is actually your issue:

https://laracasts.com/discuss/channels/general-discussion/for-those-who-find-homesteadvagrantvirtualbox-slow-on-windows/replies/20854

NFS on Windows for Vagrant. Haven't tried it myself though.

@layer7 I have tried setting the values as in this chapter 12.3.7. Long delays when accessing shared folders but it does not make a difference.

I have copied the entire repository to a different SSD drive and changed the database to use sqlite. Then I ran php artisan server and with debugbar enabled it said:

Booting (254.75ms)
Application (67.56ms)
After application (17.47ms)

TTFB = 401ms

Then I disabled debugbar and all other service providers that I have installed, but noticed little change only. TTFB is now 338ms.

I don't get it. I have copied and ran the project on both SSD and HDD and they get the same TTFB speed. So the drive speed is not the issue, but I am worried why am I getting so long booting time.

Still from homestead I get TTFB around 1.5s.

I will try to use the NFS package you suggested and report back.

So it seems that a fresh Laravel installation on my SSD (host machine) has TTFB 200ms. BTW my SSD can read 480MB/sec. 6 cores that run at 4.0GHz and 8GB of RAM. Why is this not faster??

@mabasic It doesn't really matter on what kind of disk the files reside if the VirtualBox shared folders are your issue. Try ssh'ing into your VM and copy your files somewhere -outside- of the virtualbox shared folders.

For example, if you have your files in /home/vagrant/code/myproject with a virualhost name "myproject.dev" you could do this:

sudo cp -ar /home/vagrant/code/myproject /opt/
sudo sed -i 's/\/home\/vagrant\/code\/myproject\/public/\/opt\/myproject\/public/g' /etc/nginx/sites-available/myproject.dev
sudo service nginx restart

That changes your code to a location (temporary of course) outside of vboxsf. Sure, you can't get to the code anymore through the shared folder, but at least you can verify if that is your issue or not.

PS: SSD throughput means nothing for these kinds of things. It's the -random- I/O operation specs you have to check out. Most manufacturers love to brag about their sequential throughput, but real life use is random, so those specs mean nothing. That's why enterprise SSD's cost that much more.

Cheers, K

@layer7 I will try that and report back. Thanks for your input :)

@mabasic - apologies, I should have linked to the repo I used (I got this working on Windows with VirtualBox) https://github.com/winnfsd/vagrant-winnfsd

Let me know if you get stuck - I'll do what I can to help you get it running. Hopefully it'll just work :)