# Hot reloading taking 5-10 seconds each time

**URL:** https://discourse.roots.io/t/hot-reloading-taking-5-10-seconds-each-time/25097
**Category:** bud
**Created:** 2023-04-04T19:24:57Z
**Posts:** 24

## Post 1 by @RobDobsonNC — 2023-04-04T19:24:57Z

I’ve a Lima server, running Trellis/Bedrock/Sage on a Mac. Each save takes around 5-10 seconds for the site to reload - sometimes reloading and losing all CSS before finally refreshing. I don’t touch anything other than save, and yarn dev does the rest.

This is much slower than on Virtual Box, oddly, so I’m wondering if I’ve got something wrong or where I should look to speed this up.

(starting a new thread as requested by @ben )

---

## Post 2 by @RobDobsonNC — 2023-04-06T15:37:13Z

Anybody else have this issue? I’ve tried to track it down but struggling, so any pointers would be hugely appreciated

---

## Post 3 by @ben — 2023-04-06T15:42:25Z

Are you able to reproduce this issue on a fresh install of Sage with no modifications made?

Are you running `yarn dev` from the VM or from your host machine?

What version of Node are you using?

---

## Post 4 by @RobDobsonNC — 2023-04-06T15:58:38Z

Hi Ben

This was a fresh install, so latest versions running yarn from host not VM. I’ll try a fresh install this weekend and report back.

---

## Post 5 by @RobDobsonNC — 2023-04-06T22:10:15Z

OK, so fresh install, everything ‘new’. Trellis/Bedrock/Sage, running on Lima, MacOS.

localhost:3000 seems to be the issue; it responds generally very slowly on Lima (was previously not to bad on Virtual box), so perhaps not a specific issue related to Trellis, etc.

Console tells me:

`http://localhost:3000/runtime.js.map` is not found, with a 404 error

Which I’m not sure is particularly relevant.

When I make a simple change in the base install of sage, it waits for around 5 seconds for localhost to respond, then a further 5 to download the stylesheet. This happens very time.

So possibly an issue with my httpd.conf file, from what I can find on a search?

---

## Post 6 by @ben — 2023-04-07T14:52:59Z

I’m a little confused because the dev server doesn’t serve a stylesheet — changes are injected via JS. What stylesheet is being downloaded?

Is the dev server (`http://localhost:3000`) slow when you try to navigate around the site? Or is it only slowing down after you’ve made a change to the assets?

---

## Post 7 by @RobDobsonNC — 2023-04-07T15:14:13Z

It’s slow all the time, even just loading localhost:3000. Here’s a screenshot of the console:

 ![Screenshot 2023-04-07 at 16.11.59](https://discourse.roots.io/uploads/default/original/2X/0/07c74a9ab08856b0884890bdf739e6e2f65f3d61.png)

This is just a blank install of sage/bedrock/trellis on lima.

---

## Post 8 by @ben — 2023-04-07T15:21:58Z

Does the site that is being proxied by the dev server (`http://example.test`) load quickly, or is that also slow?

---

## Post 9 by @RobDobsonNC — 2023-04-07T15:35:06Z

Example.test is much faster:

 ![Screenshot 2023-04-07 at 16.34.22](https://discourse.roots.io/uploads/default/original/2X/7/79ed63e9f5659047ecece4d1671ad456eb898e1e.png)

---

## Post 10 by @talss89 — 2023-04-07T16:30:57Z

Sorry to chip in late here, but is DNS resolution fast from the point-of-view of `bud dev`?

I’ve seen this sort of latency (admittedly in other scenarios), when the DNS server list contains an address that is unreachable; perhaps on another unrouteable subnet, or a local DNS proxy that’s misconfigured.

If you `dig example.test` from within VM / Lima - how does that perform?

edit: Was just mowing the lawn, and realised (obviously :roll_eyes:) it should be hitting a host file record, not reaching NS. But perhaps that’s misconfigured.

---

## Post 11 by @swalkinshaw — 2023-04-07T17:27:08Z

Can you hover over the `localhost` item in that network console and take a screenshot of the timing breakdown (or click the Timing tab)? It will provide clues about DNS resolution.

And run `ping localhost` to verify response times. If DNS + ping all respond quickly (as they should), then it points to an issue within `yarn dev` (in bud I assume) and likely not networking.

---

## Post 12 by @talss89 — 2023-04-07T17:30:34Z

> [@swalkinshaw](#):
>
> And run `ping localhost` to verify response times

I was thinking more along the lines of the resolution of Bud’s request to the proxy URL, not host machine localhost resolution.

---

## Post 13 by @RobDobsonNC — 2023-04-07T18:58:06Z

Thanks for everyone’s help on this. Here’s the screenshot:

 ![Screenshot 2023-04-07 at 19.54.13](https://discourse.roots.io/uploads/default/original/2X/d/da2e0ae0ddd08e9700790a45c8f6752461e3a0b5.png)

Pinging localhost seems fine and responsive:

 ![Screenshot 2023-04-07 at 19.55.36](https://discourse.roots.io/uploads/default/original/2X/f/f63b4d8e93c552070c1004b23cf33a1c5ad7a50e.png)

`Dig example.test` from within Lima gives me this:

 ![Screenshot 2023-04-07 at 19.56.59](https://discourse.roots.io/uploads/default/original/2X/0/08030657eaf4b52acfb0278c2bbdbed9fa9bf3bd.png)

---

## Post 14 by @talss89 — 2023-04-07T19:16:11Z

Thanks @RobDobsonNC!

That looks like a DNS resolver issue. The fact that the query timed out twice before resolving fairly fast (from the same NS), would cause the exact issue you’re experiencing with a long TTFB on the HMR server.

As for why… I am stumped! I was expecting it to be trying a number of IPs, before finally resolving…

[Here’s some info on how Lima’s DNS resolution system works.](https://lima-vm.io/?file=docs/network.md#:~:text=If%20useHostResolver%20in,address%20(on%20macOS).)

@swalkinshaw - Can you shed any light on how Lima’s resolver works? Will Trellis set `useHostResolver` to true or false? Seems like there are some caveats, and a compiler flag that needs to be set in some cases. `CGO_ENABLED=1`

---

## Post 15 by @swalkinshaw — 2023-04-08T19:56:26Z

:thinking: I wonder if you have another DNS server running on your Mac or conflicting entries for `.test` domains. Laravel Valet also handles that for example. Do you know if you’re running that?

Seeing `127.0.0.53` as your DNS server was interesting. Mine is `192.0.2.42` for example.

Can you run `cat /etc/resolv.conf` as well?

> [@talss89](#):
>
> @swalkinshaw - Can you shed any light on how Lima’s resolver works? Will Trellis set `useHostResolver` to true or false? Seems like there are some caveats, and a compiler flag that needs to be set in some cases. `CGO_ENABLED=1`

I don’t really know much more beyond that. Except that Go finally fixed DNS resolution as of 1.20 so `CGO_ENABLED` isn’t needed anymore.

edit: I don’t think those time outs on port 53 are Lima’s hostagent though since that binds to a free port (in a much higher range).

---

## Post 16 by @RobDobsonNC — 2023-04-08T22:49:02Z

Thanks both of you, again, I really appreciate the help.

So I did have valet installed previously when looking at using Trellis; I removed it though a while ago. I have local installed, using .local domains, but that’s not currently running at all.

Running `cat /etc/resolve` gives the following:

```
# macOS Notice

#

# This file is not consulted for DNS hostname resolution, address

# resolution, or the DNS query routing mechanism used by most

# processes on this system.

#

# To view the DNS configuration used by this system, use:

# scutil --dns

#

# SEE ALSO

# dns-sd(1), scutil(8)

#

# This file is automatically generated.

#

search Home

nameserver 192.168.0.1

nameserver fdd8:68b5:5d04:0:26a7:dcff:fe78:3a00
```

Running `scutil --dns` gives this:

```
DNS configuration

resolver #1
  search domain[0] : Home
  nameserver[0] : 192.168.0.1
  nameserver[1] : fdd8:68b5:5d04:0:26a7:dcff:fe78:3a00
  if_index : 6 (en0)
  flags : Request A records, Request AAAA records
  reach : 0x00020002 (Reachable,Directly Reachable Address)

resolver #2
  domain : local
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 300000

resolver #3
  domain : 254.169.in-addr.arpa
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 300200

resolver #4
  domain : 8.e.f.ip6.arpa
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 300400

resolver #5
  domain : 9.e.f.ip6.arpa
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 300600

resolver #6
  domain : a.e.f.ip6.arpa
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 300800

resolver #7
  domain : b.e.f.ip6.arpa
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 301000

resolver #8
  domain : test
  nameserver[0] : 127.0.0.1
  flags : Request A records, Request AAAA records
  reach : 0x00030002 (Reachable,Local Address,Directly Reachable Address)

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : Home
  nameserver[0] : 192.168.0.1
  nameserver[1] : fdd8:68b5:5d04:0:26a7:dcff:fe78:3a00
  if_index : 6 (en0)
  flags : Scoped, Request A records, Request AAAA records
  reach : 0x00020002 (Reachable,Directly Reachable Address)
```

And when I start `trellis vm start` it **also** takes three tries to get the initial test completed:

```
Running command => limactl start example.com
INFO[0000] Using the existing instance "example.com"    
INFO[0001] [hostagent] Starting VZ (hint: to watch the boot progress, see "/Users/robdobson/.lima/example.com/serial.log") 
INFO[0001] SSH Local Port: 51121                        
INFO[0001] [hostagent] [VZ] - vm state change: running  
INFO[0001] [hostagent] Waiting for the essential requirement 1 of 3: "ssh" 
INFO[0001] [hostagent] new connection from to          
INFO[0004] [hostagent] 2023/04/08 23:36:20 tcpproxy: for incoming conn 127.0.0.1:51125, error dialing "192.168.5.15:22": connect tcp 192.168.5.15:22: no route to host 
INFO[0014] [hostagent] Waiting for the essential requirement 1 of 3: "ssh" 
INFO[0016] [hostagent] 2023/04/08 23:36:32 tcpproxy: for incoming conn 127.0.0.1:51128, error dialing "192.168.5.15:22": connect tcp 192.168.5.15:22: connection was refused 
INFO[0026] [hostagent] Waiting for the essential requirement 1 of 3: "ssh" 
INFO[0029] [hostagent] The essential requirement 1 of 3 is satisfied 
INFO[0029] [hostagent] Waiting for the essential requirement 2 of 3: "user session is ready for ssh" 
INFO[0042] [hostagent] Waiting for the essential requirement 2 of 3: "user session is ready for ssh" 
INFO[0042] [hostagent] The essential requirement 2 of 3 is satisfied 
INFO[0042] [hostagent] Waiting for the essential requirement 3 of 3: "the guest agent to be running" 
INFO[0042] [hostagent] The essential requirement 3 of 3 is satisfied 
INFO[0042] [hostagent] Waiting for the final requirement 1 of 1: "boot scripts must have finished" 
INFO[0042] [hostagent] Forwarding "/run/lima-guestagent.sock" (guest) to "/Users/robdobson/.lima/example.com/ga.sock" (host) 
INFO[0043] [hostagent] The final requirement 1 of 1 is satisfied 
INFO[0043] READY. Run `limactl shell example.com` to open the shell. 

Updating /etc/hosts file (sudo may be required, see `trellis vm sudoers` for more details)
```

---

## Post 17 by @swalkinshaw — 2023-04-08T23:50:15Z

> [@RobDobsonNC](#):
>
> ```
> resolver #8
> domain : test
> nameserver[0] : 127.0.0.1
> flags : Request A records, Request AAAA records
> reach : 0x00030002 (Reachable,Local Address,Directly Reachable Address)
> ```

This is the problem here. Some other DNS server is set up for `.test` and has a default timeout of 5 seconds.

You’ll have to run `lsof` and find what process is listening on that port. Run `sudo lsof -n -i -P | grep LISTEN` and look for port 53.

Also check for files in `/etc/resolver/`

---

## Post 18 by @RobDobsonNC — 2023-04-09T10:10:25Z

Ah. Possibly due to a previous install of either VM or similar I guess. On port 53 I have:

```
mDNSRespo 223 _mdnsresponder 48u IPv4 0x20108fb09042c09 0t0 TCP *:53 (LISTEN)
mDNSRespo 223 _mdnsresponder 52u IPv6 0x20108f64641e3c1 0t0 TCP *:53 (LISTEN)
```

resolver just holds:

`nameserver 127.0.0.1`

---

## Post 19 by @RobDobsonNC — 2023-04-09T10:21:13Z

Removing the content of resolver gives me this result, much quicker. Does this seem about what’s expected?

 ![Screenshot 2023-04-09 at 11.20.01](https://discourse.roots.io/uploads/default/original/2X/b/ba54b511979e60c29ce0ac558c23bc1079941fcd.png)

---

## Post 20 by @swalkinshaw — 2023-04-09T13:58:30Z

Well it definitely removed the 5s timeout :sweat_smile: I have that mDNS process running too but the culprit was the file in `/etc/resolver`. At some point, some tool create that file there so any request for `.test` was being served.

---

## Post 21 by @RobDobsonNC — 2023-04-09T15:06:50Z

Saved me a few hours this week! Thanks for your help!

---

## Post 22 by @N1Prop — 2023-09-21T17:44:52Z

I have a very similar issue except it takes about 10 sec to load my local .test site  
as @swalkinshaw pointed out I had test file in /etc/resolver/ . I deleted it but this didn’t fix the problem. I do have some errors when ‘trellis vm start’ but not sure that they are critical as the vm starts and my local site gets served (with about 10 sec delay for each request). I would appreciate any pointers to move forward

Thank you

**trellis vm start**

```
Alexis-MacBook-Pro-2:trellis AY$ trellis vm start
Running command => limactl start ezlendr.com
INFO[0000] Using the existing instance "ezlendr.com"
WARN[0000] Ignoring: vmType vz: [OS]
INFO[0000] [hostagent] Starting VZ (hint: to watch the boot progress, see "/Users/AY/.lima/ezlendr.com/serial*.log")
INFO[0000] [hostagent] new connection from to
INFO[0001] SSH Local Port: 49513
INFO[0001] [hostagent] Waiting for the essential requirement 1 of 3: "ssh"
INFO[0001] [hostagent] [VZ] - vm state change: running
INFO[0011] [hostagent] Waiting for the essential requirement 1 of 3: "ssh"
INFO[0011] [hostagent] 2023/09/21 13:04:13 tcpproxy: for incoming conn 127.0.0.1:49529, error dialing "192.168.5.15:22": connect tcp 192.168.5.15:22: connection was refused
ERRO[0016] [hostagent] r.CreateEndpoint() = no route to host
ERRO[0017] [hostagent] r.CreateEndpoint() = no route to host
ERRO[0017] [hostagent] r.CreateEndpoint() = no route to host
ERRO[0019] [hostagent] r.CreateEndpoint() = no route to host
INFO[0021] [hostagent] Waiting for the essential requirement 1 of 3: "ssh"
INFO[0022] [hostagent] The essential requirement 1 of 3 is satisfied
INFO[0022] [hostagent] Waiting for the essential requirement 2 of 3: "user session is ready for ssh"
INFO[0022] [hostagent] The essential requirement 2 of 3 is satisfied
INFO[0022] [hostagent] Waiting for the essential requirement 3 of 3: "the guest agent to be running"
INFO[0022] [hostagent] The essential requirement 3 of 3 is satisfied
INFO[0022] [hostagent] Waiting for the final requirement 1 of 1: "boot scripts must have finished"
INFO[0022] [hostagent] Forwarding "/run/lima-guestagent.sock" (guest) to "/Users/AY/.lima/ezlendr.com/ga.sock" (host)
INFO[0022] [hostagent] The final requirement 1 of 1 is satisfied
INFO[0022] READY. Run `limactl shell ezlendr.com` to open the shell.

Updating /etc/hosts file (sudo may be required, see `trellis vm sudoers` for more details)

Your Trellis VM is ready to use!

* Composer and WP-CLI commands need to be run on the virtual machine for any post-provision modifications.
* You can SSH into the machine with 'trellis vm shell'
* Then navigate to your WordPress sites at '/srv/www'
```

**lsof -n -i -P | grep LISTEN**

```
rapportd 550 AY 3u IPv4 0x110b471f8a2abb7d 0t0 TCP *:49179 (LISTEN)
rapportd 550 AY 4u IPv6 0x110b471127887ed5 0t0 TCP *:49179 (LISTEN)
GitHub 828 AY 27u IPv4 0x110b471f8a2b0efd 0t0 TCP 127.0.0.1:49310 (LISTEN)
bridge 1062 AY 12u IPv4 0x110b471f855218bd 0t0 TCP 127.0.0.1:49433 (LISTEN)
bridge 1062 AY 23u IPv4 0x110b471f862158bd 0t0 TCP 127.0.0.1:1143 (LISTEN)
bridge 1062 AY 24u IPv4 0x110b471f8620fa1d 0t0 TCP 127.0.0.1:1025 (LISTEN)
limactl 1172 AY 10u IPv4 0x110b471f8620bcdd 0t0 TCP 127.0.0.1:49514 (LISTEN)
limactl 1172 AY 22u IPv4 0x110b471f86206efd 0t0 TCP 127.0.0.1:49513 (LISTEN)
limactl 1172 AY 45u IPv4 0x110b471f861ffa1d 0t0 TCP *:80 (LISTEN)
ssh 1210 AY 7u IPv4 0x110b471f870bdefd 0t0 TCP 127.0.0.1:11211 (LISTEN)
ssh 1210 AY 10u IPv4 0x110b471f870c005d 0t0 TCP 127.0.0.1:8025 (LISTEN)
ssh 1210 AY 14u IPv4 0x110b471f870b3cdd 0t0 TCP 127.0.0.1:3306 (LISTEN)
```

**scutil --dns**

```
DNS configuration

resolver #1
  nameserver[0] : 23.252.205.6
  nameserver[1] : 23.252.205.7
  nameserver[2] : 24.238.0.53
  nameserver[3] : 8.8.8.8
  if_index : 5 (en0)
  flags : Request A records, Request AAAA records
  reach : 0x00000002 (Reachable)

resolver #2
  domain : local
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 300000

resolver #3
  domain : 254.169.in-addr.arpa
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 300200

resolver #4
  domain : 8.e.f.ip6.arpa
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 300400

resolver #5
  domain : 9.e.f.ip6.arpa
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 300600

resolver #6
  domain : a.e.f.ip6.arpa
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 300800

resolver #7
  domain : b.e.f.ip6.arpa
  options : mdns
  timeout : 5
  flags : Request A records, Request AAAA records
  reach : 0x00000000 (Not Reachable)
  order : 301000

DNS configuration (for scoped queries)

resolver #1
  nameserver[0] : 23.252.205.6
  nameserver[1] : 23.252.205.7
  nameserver[2] : 24.238.0.53
  nameserver[3] : 8.8.8.8
  if_index : 5 (en0)
  flags : Scoped, Request A records, Request AAAA records
  reach : 0x00000002 (Reachable)
```

---

## Post 23 by @Jack_Kudla — 2023-11-07T00:23:29Z

Were you able to solve your issue? I am having similar problems with Lima taking about 10 sec where my production server is functioning normally.

---

## Post 24 by @RobDobsonNC — 2023-11-07T09:12:54Z

After resolving the issues above with @swalkinshaw 's help, the next main problem was just that developing locally on my laptop was slow in general. Production servers were all fine, because they just had more power. I’m trying some remote dev server approaches at the moment, which are working ok.