Painfully slow response times in Valet + tons of 504 gateway timeouts #744

circa42 · 2019-03-12T16:52:55Z

Problems:

Regular 504 time outs
upwards of 30 seconds per reload

The whole thing is crazy slow. I have no idea where to start on how to fix this.

What I've done:
» reinstalled valet
» changed memory_limit to = 256M
» updated valet
» updated brew
» restarted valet
» restarted machine
» swore loudly

I'm running 7.1.25

Any help pointing me in the right direction would be awesome.

The text was updated successfully, but these errors were encountered:

drbyte · 2019-03-12T17:02:29Z

How long has this been happening?
When did it start?
How does that fit in relation to:
Other software updates on your machine?
Other apps created?
Network config changes?
Other composer packages installed? including composer global packages installed/updated?

Did you recently switch between PHP versions? which ones?

Is this problem manifesting only with Laravel apps? specific ones? Which non-Laravel apps?
What are the patterns of where it occurs?

Does running valet tld test (or replace test with whatever TLD you're using for your sites) help? (It rebuilds all the nginx configs for all your sites.)

When last did you run valet install?

circa42 · 2019-03-12T17:27:35Z

Great questions, @drbyte, thanks!

How long has this been happening?

Since I installed it — ±3 months ago

When did it start?

☝️

How does that fit in relation to:
Other software updates on your machine?

Not sure. I'm not doing much with installs. I'm running a pretty old machine (2011) and running High Sierra

Other apps created?

N/A—I only build Craft CMS sites.

Network config changes?
Other composer packages installed? including composer global packages installed/updated?

Not sure. I haven't seen any difference in either the amount of 504s I get or how fast the reload times are, no matter what I do to MacOS or what sort of composer packages I have. 504s are intermittent and I've always seen at least a 10-15 second reload time since the first install.

Did you recently switch between PHP versions? which ones?

I did a clean install of Valet recently (±2 months ago) and went straight to 7.1

Is this problem manifesting only with Laravel apps? specific ones? Which non-Laravel apps?

I don't do anything besides Craft CMS installs, so I couldn't say. But every single install is like this—whether I install it fresh or am installing a site I inherit.

What are the patterns of where it occurs?

No pattern for 504s. Sometimes they resolve with either multiple reloads or a valet restart. But within no time I'm back to random 504s.
Reload times are consistently slow. 15 seconds at a minimum. Often 60+ seconds.
TTFB on last reload was 37729.2ms. This screen shot is a typical network timeline: http://c42.co/8fsKOh

Does running valet tld test (or replace test with whatever TLD you're using for your sites) help? (It rebuilds all the nginx configs for all your sites.)

Just tried it — did not help. Reload time was still slow.

When last did you run valet install?

Couple of weeks ago. And again just 5 minutes ago. Does not help.

mattstauffer · 2019-03-12T17:39:04Z

@circa42 Could you try loading a site with just a straight HTML file?

Then one with a single PHP file that doesn't do anything?

<?php

echo "Hey there!";

Then, if it's easy enough, one that just connects to your database?

<?php

$host = '127.0.0.1';
$username = 'root';
$password = '';
$database = 'testing_valet';
$table = 'users';

$mysqli = new mysqli($host, $username, $password, $database);

if ($mysqli->connect_errno) {
    echo "Error: Failed to make a MySQL connection:<br>";
    echo "Errno: " . $mysqli->connect_errno . "<br>";
    echo "Error: " . $mysqli->connect_error . "<br>";

    exit;
}

$sql = "SELECT * FROM {$table}";

if (! $result = $mysqli->query($sql)) {
    echo "Error: Failed querying<br>";
    echo "Errno: " . $mysqli->errno . "<br>";
    echo "Error: " . $mysqli->error . "<br>";
    exit;
}

var_rump($result->fetch_assoc());

circa42 · 2019-03-12T17:53:28Z

@mattstauffer
Both of those test files click along nicely. TTFB is sub 13ms.

circa42 · 2019-03-12T17:57:11Z

I do get this error when trying to connect to an existing local DB:
Fatal error: Uncaught Error: Call to undefined function var_rump() in /Users/andrew/Dropbox/Sites/html/index.php:28 Stack trace: #0 /Users/andrew/.composer/vendor/laravel/valet/server.php(158): require() #1 {main} thrown in /Users/andrew/Dropbox/Sites/html/index.php on line 28

drbyte · 2019-03-12T18:03:28Z

(the var_rump thing is a typo in Matt's suggested code -- see the last line. var_dump would be better ;) and would give you the db results queried. )

circa42 · 2019-03-12T18:06:04Z

(the var_rump thing is a typo in Matt's suggested code -- see the last line. var_dump would be better ;) and would give you the db results queried. )

I'll try var_booty next time. 😂

TTFB is speedy — 93.8ms. So if TTFB is fast on these little test files—is there something weird with my Craft install?

drbyte · 2019-03-12T18:08:11Z

Maybe.
Mind installing a fresh new Laravel app and testing it?

cd Sites
composer create-project laravel/laravel speedtest
cd speedtest
valet open

drbyte · 2019-03-12T18:11:04Z

If the fresh Laravel app also exhibits the problem, then what are the results of dig example.test ?

I think there are 2 areas of interest with this situation:

PHP socket
Controlled by php and php-fpm configs, which are referred to by the nginx configs
DNS lookups
Controlled by dnsmasq config and OSX network settings

mattstauffer · 2019-03-12T18:11:32Z

LOLOL var_rump i'm gonna call it a day

circa42 · 2019-03-12T18:33:14Z

@drbyte — a fresh Laravel install yields anywhere between a sub 150ms to a +5s TTFB.

drbyte · 2019-03-12T18:36:28Z

I wonder how that compares with a fresh Craft site?

Again, looking for patterns here, or even better: looking to isolate what produces the symptoms.

circa42 · 2019-03-12T20:22:42Z

Interesting. A fresh Craft install gave me a 504 time out right off the bat. Then a few more refreshes and it showed up with a TTFB of 795ms.

havardlj · 2019-03-28T07:46:46Z

Did you ever get to the bottom of this? I am having the exact same problem, wondering if it has something to do with a past Homestead install

circa42 · 2019-03-29T01:22:32Z

Honestly, I think the problem (for me, at least) is that I needed upgrade my macOS. (I’ve heard it something’s doesn’t play nice the High Seirra) My computer was old enough that I had to buy a new machine.

Whether it was the macOS, or not having some random crapware on my machine slowing things down, either way I’m back in business.

larssn · 2019-04-01T16:58:32Z

Had a related issue with a 2011 mac and high sierra: Basically dnsmasq didnt start up. I just installed valet.

So I did this:
brew services stop dnsmasq
sudo brew services stop dnsmasq
valet restart

That fixed it

terryupton · 2019-06-07T09:38:13Z

@circa42 - did you manage to solve this? I am seeing the same issues. I am also building Craft sites.

circa42 · 2019-06-07T15:35:23Z

My solution isn't an overly viable one, but yes I did solve it by buying a new iMac. 🙄

terryupton · 2019-06-07T15:43:04Z

my iMac is new and super specced so wasn't the issue.
Fortunately, I have found and resolve the issue though. Was down to a plugin and some missing elements on my side.

Flimm · 2019-10-02T15:10:33Z

I have been suffering with a slow Valet setup, thinking the problem was that WordPress was slow all along. I just tried a different set up (not Valet), and now I get response within 0.1s instead of 2s with Valet. I know that I'm not giving enough information to be helpful to Valet developers, but I did want to help lurkers and encourage them to investigate not just your PHP application, but also your setup.

terryupton · 2019-10-02T16:06:02Z

What setup did you use @Flimm ?

drbyte · 2019-10-02T16:23:15Z

@Flimm ... and was the slowness only with Wordpress?

simplenotezy · 2019-10-29T13:18:16Z

@Flimm I have the same issues. It's basically ruining my workday. Which other setup did you choose? 😊

Flimm · 2019-10-31T07:52:16Z

To respond to @terryupton , @drbyte , @simplenotezy , I'm afraid that I didn't have time to investigate properly the causes, so I can't be 100% sure that the problem was with Valet. It wasn't an issues of slowness just with WordPress, other PHP applications were also slow. I eventually tried Local by Flywheel, and MAMP. I only wanted to encourage lurkers to investigate other options.

timgavin · 2019-11-03T16:27:23Z

I bought a new iMac a few months ago and it's been painfully slow, to the point where it would take several seconds just for an Alfred prompt to show, then another 5-10 seconds just to type something in. Photoshop and email took minutes to launch...

I finally decided to get to the bottom of it today and started uninstalling apps, but nothing helped. I then decided to do valet stop and HOLY CRAP. Photoshop now takes seconds to launch. Everything is as it should be; my Mac is fast again.

So something in the Valet install is killing my Mac...

drbyte · 2019-11-03T16:51:12Z

valet stop simply tells homebrew to stop nginx and php.
You could explore further by running brew services list and starting/stopping services to see which specifically affects things. Note that things shown running as root should be started/stopped using sudo.

Then when you identify which service is related to the slowdown, you can go explore its config files and/or any other services that might be conflicting with that service (or any added extensions/etc that you've added that could be contributing).

timgavin · 2019-11-03T20:34:56Z

@drbyte Here's what's weird. When I run valet stop my Mac speeds up. When I check brew services list I see that nginx has stopped. Yet when I start nginx back up my Mac still runs fast. When I run valet start it slows down again, and when I run valet stop it speeds up again. *shrug*

drbyte · 2019-11-03T20:35:54Z

So it must be something with your PHP install then?

timgavin · 2019-11-03T20:46:00Z

Mac is running slow...

tim: ~ $ valet stop
Stopping php...
Stopping nginx...
Valet services have been stopped.
tim: ~ $ brew services list
Name      Status  User Plist
dnsmasq   started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
mysql@5.7 started tim  /Users/tim/Library/LaunchAgents/homebrew.mxcl.mysql@5.7.plist
nginx     started tim  /Users/tim/Library/LaunchAgents/homebrew.mxcl.nginx.plist
php       started tim  /Users/tim/Library/LaunchAgents/homebrew.mxcl.php.plist
tim: ~ $

Mac is now running fast. Let's check...

tim: ~ $ brew services start php
Service `php` already started, use `brew services restart php` to restart.
tim: ~ $ brew services start nginx
Service `nginx` already started, use `brew services restart nginx` to restart.

So, it looks like Valet didn't actually stop nginx or PHP, as they're still running, and my Mac is no longer slow until I run valet start again.

mattstauffer · 2019-11-04T16:47:17Z

valet/cli/valet.php

Line 252 in 12f75fc

$app->command('stop', function () {

OK, so valet stop does two things: stop Nginx and stop PHP.

Curiously, my nginx and php processes run as root, not mattstauffer, so i wonder whether trust is at play here.

I'm showing nginx as correctly stopping when I run valet stop but php keeps running, for whatever good that does.

So let's dig into what Valet telling nginx to stop does:

valet/cli/Valet/Nginx.php

Line 159 in 12f75fc

    
           $this->cli->quietly('sudo brew services stop '. $this->brew->nginxServiceName());

runs sudo brew services stop nginx

And what it telling PHP to stop does:

valet/cli/Valet/PhpFpm.php

Line 125 in 12f75fc

function stopRunning()

brew -> stopService ->all running services which start with php.
In your case, this should run

sudo brew services stop php

... which doesn't seem to have any impact on your computer.

I just noticed something. If I try to run that same command:

So if my services are started as mattstauffer and then Valet tries to stop them with sudo it throws an error. If I stop them manually and then valet start again, now they're started as root.

I can't imagine how that would solve this mysterious problem, but hey, at least it might get your computer into a more predictable state?

timgavin · 2019-11-06T23:25:10Z

Thanks Matt; apologies for the delay. This is a very strange issue, because PHP and nginx keep bouncing back and forth between starting as root, and when I stop and restart it doesn't seem to have any effect one way or the other. Sometimes everything slows down, other times it doesn't, and I haven't been able to find a pattern as to why. It's currently running well, so I'm just going to leave it alone in fear it'll start crawling again. Someday when I find the time I'll probably just uninstall everything and start over. Thanks! I appreciate your help!

Trashpants · 2020-01-09T11:57:16Z

So I had this problem all last night super random - 40-400s page loads, certain projects just flat out 504

Turns out that after I upgraded to php 7.4.1 the mysql (v8.0.18) user id made with mysql_native_password no longer works - setting this back to caching_sha2_password it worked instantly.

Something to definitely check as there was nothing obvious that pointed to this being an issue at all

tyssen · 2020-01-28T06:44:06Z

@Trashpants can you expand a bit on what you did to reset back to caching_sha2_password please? I formatted my 2012 MacBook Pro's HD on the weekend and did a clean install of Catalina and then installed Valet and I'm getting a lot of slow loading times and 504s too. I've tested sites running a few different CMSs including Craft, ExpressionEngine and Processwire and getting similar performance from all of them.

Trashpants · 2020-01-28T08:45:27Z

@tyssen honestly the easiest way to check if the DB user is an issue is to comment them out in your .env file. If things go back to what you’d expect then check the return of:

select user,host,plugin from mysql.user;

Gives your user a plugin value of caching_sha2_password.

If you make a brand new user on the DB and you don’t alter the plugin value you will automatically get caching_sha2_password

tyssen · 2020-01-28T09:16:42Z

I created a new user which was assigned the caching_sha2_password plugin and assigned it to my sites, and I'm still getting the same sort of response times as before.

tyssen · 2020-01-28T10:36:53Z

I've added a Statamic site to valet now and it's running a lot more quickly than the ones using a database. Although when I do a test on a static PHP file v the db connect example Matt gave above, I'm not seeing much variation. Certainly not as much as doing the same TTFB test on a page being served by the CMS.

https://domain.test/test.php # Hello world PHP example

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    10    0    10    0     0     40      0 --:--:-- --:--:-- --:--:--    40

Connect: 0.030207 TTFB: 0.249394 Total time: 0.249709

https://domain.test/db.php # Matt's db connect example

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   446    0   446    0     0   2548      0 --:--:-- --:--:-- --:--:--  2548

Connect: 0.022492 TTFB: 0.175551 Total time: 0.175820

https://domain.test/ # CMS site home page

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 68992    0 68992    0     0  22913      0 --:--:--  0:00:03 --:--:-- 22913

Connect: 0.018687 TTFB: 2.977444 Total time: 3.011436

RyanRoberts · 2020-01-30T14:27:33Z

I've been having this exact same problem. Everything is up to date, including Craft CMS, and I have a beefy 2019 MBP.

Out of interest, is anyone also experiencing this problem using CloudFlare's 1.1.1.1 DNS in macOS? You set it in Sys Prefs > Network > Advanced > DNS: DNS Servers.

Since removing CloudFlare's servers all my Craft sites on Valet have gone from 20-30 second load times to less than a second or two (depending on the site). This may be a coincidence so I'll keep an eye on what happens.

drbyte · 2020-01-30T14:40:45Z

Out of interest, is anyone also experiencing this problem using CloudFlare's 1.1.1.1 DNS in macOS? You set it in Sys Prefs > Network > Advanced > DNS: DNS Servers.

Since removing CloudFlare's servers all my Craft sites on Valet have gone from 20-30 second load times to less than a second or two (depending on the site). This may be a coincidence so I'll keep an eye on what happens.

Last night I found Cloudflare's DNS was causing delays in everything using it. Seems to be moderately better this morning.

My preferred way of controlling external DNS when Valet is installed is to create custom dnsmasq configs for the various providers I might use is documented here:
#736 (comment)
(and then MacOS's DNS server list is just 127.0.0.1 so dnsmasq can provide it when needed, with fewer timeouts)

I have separate configs I enable/disable for Cloudflare, OpenDNS, Google, etc. I normally prefer cloudflare's 1.1.1.1 ... until last night's incident.

EDIT: Update: The CloudFlare issue was very temporary.

havardlj · 2020-06-25T14:30:23Z

I got a new mac, reinstalled brew and valet, and Craft ended up working flawlessly. After several months, the same problem returned. I have not I have yet to get any timeout errors, but every request takes over 10 seconds. I installed the latest update for my mac yesterday, but the problem started occurring today after a restart. I have tried everything in thread. I don't have any CloudFlare servers in my DNS server list. Could this have anything to do with my VPN service?

drbyte · 2020-06-25T14:41:29Z

@havardlj it would be preferable for you to open a new ticket for this. You can mention that you reviewed this Issue.

When you make that post, answer the questions posed in the New Issue template, and expand on the following as well:

I installed the latest update for my mac yesterday

Do you mean a MacOS update? Or homebrew updates?
What was the MacOS version before and after?
Any other updates you installed?
Anything "else" besides Valet (er, Craft in your case) that's slow?

Could this have anything to do with my VPN service?

In the absence of any explanation of said VPN service I'll say: yes. Until you rule it out.
ie: is there a difference with the VPN turned off? if there is, then you've got a clear direction to explore. If not, please describe how the VPN is configured/installed, and what software is running it.

Posting the output from valet diagnose could be helpful.

erikwestlund · 2021-05-05T00:42:51Z

I have a brand new Big Sur set up on 2019 Macbook Pro and the TTFBs with Laravel are just dreadful. Usually close to a second. When I just load an index.php w/ Laravel and connected to a database, and exit out before booting the framework, it's basically instant. Not sure why it's so darn slow.

drbyte · 2021-05-05T00:45:18Z

@erikwestlund please open a new Issue, including the output of valet diagnose

mattstauffer closed this as completed Apr 3, 2019

havardlj mentioned this issue Jun 26, 2020

More slow response times in Valet + tons of 504 gateway timeouts #965

Closed

justenh mentioned this issue Jun 26, 2020

Craft3 Timeouts and Super Slow Response #966

Closed

havardlj mentioned this issue Jun 30, 2020

Slow response time and 504 timeouts in Laravel Valet. craftcms/cms#6289

Open

Painfully slow response times in Valet + tons of 504 gateway timeouts #744

Painfully slow response times in Valet + tons of 504 gateway timeouts #744

Comments

circa42 commented Mar 12, 2019

drbyte commented Mar 12, 2019

circa42 commented Mar 12, 2019 • edited Loading

mattstauffer commented Mar 12, 2019

circa42 commented Mar 12, 2019

circa42 commented Mar 12, 2019

drbyte commented Mar 12, 2019

circa42 commented Mar 12, 2019

drbyte commented Mar 12, 2019

drbyte commented Mar 12, 2019

mattstauffer commented Mar 12, 2019

circa42 commented Mar 12, 2019

drbyte commented Mar 12, 2019

circa42 commented Mar 12, 2019

havardlj commented Mar 28, 2019

circa42 commented Mar 29, 2019

larssn commented Apr 1, 2019

terryupton commented Jun 7, 2019

circa42 commented Jun 7, 2019

terryupton commented Jun 7, 2019

Flimm commented Oct 2, 2019

terryupton commented Oct 2, 2019

drbyte commented Oct 2, 2019

simplenotezy commented Oct 29, 2019 • edited Loading

Flimm commented Oct 31, 2019

timgavin commented Nov 3, 2019

drbyte commented Nov 3, 2019

timgavin commented Nov 3, 2019

drbyte commented Nov 3, 2019

timgavin commented Nov 3, 2019

mattstauffer commented Nov 4, 2019

timgavin commented Nov 6, 2019

Trashpants commented Jan 9, 2020

tyssen commented Jan 28, 2020

Trashpants commented Jan 28, 2020

tyssen commented Jan 28, 2020

tyssen commented Jan 28, 2020

RyanRoberts commented Jan 30, 2020 • edited Loading

drbyte commented Jan 30, 2020 • edited Loading

havardlj commented Jun 25, 2020

drbyte commented Jun 25, 2020

erikwestlund commented May 5, 2021

drbyte commented May 5, 2021

circa42 commented Mar 12, 2019 •

edited

Loading

simplenotezy commented Oct 29, 2019 •

edited

Loading

RyanRoberts commented Jan 30, 2020 •

edited

Loading

drbyte commented Jan 30, 2020 •

edited

Loading