Q: Date/Time this occurred (Provide your time zone also)
A:~Over the last month
Q: DevKinsta Version
**A:**2.6.0
Q: OS Version
**A:**macOS 12.4
Q: Docker Desktop Version
**A:**4.9.1
Q: Were any error codes or messages observed? If so, what were they?
**A:**504 Gateway Time-out (nginx)
Q: Detailed Description of the Problem
A:
Had no problems with dev kinsta up until a couple of weeks ago I rebuilt my entire dev environment from scratch because of an accidental database deletion locally (when testing migrations) - my first time building an env since ~Feb 2021.
Not sure what’s happened in that time, but pages now taking 40+ seconds to load sometimes, with an average of 20+ seconds overall. It’s kind of completely unworkable and really slows down my ability to be productive. (Production is near-instant when performing similar/the same operations)
However since then, my entire local environment is bricked. It’s not that pages load slowly, they just don’t load now full stop.
I’ve tried rebuilding, upgrading everything to the latest versions, and enabling vritiofts in Docker, but alas no dice.
No idea what or why this is happening.
Resources allocated to docker (I have no other images installed, any other dev environments running, or any other kinsta sites installed locally)
(Related conversation where I was told to start a new topic for this issue) Website Interactivity is Slow - #66 by Kevin
Kevin
(Kevin)
2
Thanks @devstagr, I’ll be looking into this today. Does restarting the devkinsta_fpm container or the devkinsta_nginx containers solve the 504 error at all or is it always present now?
Also, what happens if you create a fresh WordPress site within DevKinsta? Do you have the same performance issues?
Makes no difference, it’s eternally stuck now.
A fresh site that’s built on the existing site I’m trying to replicate? Or do you mean an entirely vanilla wordpress installation
Kevin
(Kevin)
4
I would try with a vanilla WP installation. I want to rule out issues with the site itself/make sure it’s a 504 no matter what.
So the vanilla installation seems to load faster, still not very fast, but certainly at a useable speed (although had to restart my machine for the installation to finish because of a random nginx error)
Main site I’m trying to work seems to load a little bit on /wp-admin after a long while, but navigating to /wp-admin/edit.php it just goes back to the 504 error once again
Kevin
(Kevin)
6
Hmm okay. I’m going to assume you didn’t add any new code or plugins that would affect wp-admin.
Can you go to terminall and run the command docker stats?
Can you get a screenshot of how that looks when you load the /wp-admin/edit.php page? For example mine looks like this:
Can you also private message your php-fpm and error logs for this site? They will be in ~/DevKinsta/logs
Kevin
(Kevin)
8
Interesting, you’re running out of PHP workers.:
[13-Jun-2022 10:15:41] WARNING: [pool www] server reached max_children setting (4), consider raising it
Let’s try increasing that to something like 12 to see if you still timeout. You can do that by going to Docker Desktop and opening the terminal for the devkinsta_fpm container:
Once in the terminal run these commands:
sudo apt-get updatesudo apt-get install nano nano /etc/php/7.4/fpm/pool.d/www.conf
Now edit the pm.max_children to a higher number. I would start by doubling it to 8.
After you change it to 8 and save the file you can use this command to make sure it saved correctly:
grep "max_children" /etc/php/7.4/fpm/pool.d/www.conf
Now you just need to restart the container. It’s easiest to do this from Docker Desktop:
After all that try loading that edit page again. If it ends in a 504 again, please check the php7.4-fpm.log to see if it is returning a “max_children” error still even with 8.
So far I feel like your site is needing more PHP workers than are available but your Mac should be able to handle more based on how much memory you have to spare.
Please let me know if you run into any issues here. I never realized how unintuitive this process was so I’ll definitely bring it up with the developers if this ends up being the issue for your site.
Hmmm, can’t get nano installed (vim doesn’t appear to be installed either) - is there some config option somewhere preventing external apps being installed?
Kevin
(Kevin)
10
No, I’m not sure what that’s about. I got the same error the first time I tried running apt-get update. It eventually went through. I’m guessing there’s some genuine issue going on with the archives. I would try again a few more times.
Tried a few times last night and this morning but to no avail - same error.
Is networking disabled? I can’t even run the ping command to test external network connections because it’s not installed/enabled inside of the fpm container
Kevin
(Kevin)
12
Yes networking is enabled. There are very few packages installed to keep the container size down. You can try an ssh command to be sure though. The general one in MyKinsta for connecting to your container should work.
Now I’m not sure why it worked for me the second time. I’m also able to install vim without issue. This might work: https://askubuntu.com/a/1385445 The only change I made to this was using curl -O https://... because wget does is not installed either.
I’ll also point this out to our developers
Hmm no dice. SSH to an external server worked first time with no issue, so probably not network related then.
Using curl on that URL I end up with
curl: (6) Could not resolve host: gist.githubusercontent.com
Kevin
(Kevin)
14
Huh, that’s weird. That one worked right away for me. Okay I’m off for the weekend but will check on this again Monday.
You can actually use the oldschool method to do this. Just using cat like this:
cat /etc/php/7.4/fpm/pool.d/www.conf- copy the output of that file to a texteditor and make your changes.
cat > /etc/php/7.4/fpm/pool.d/www.conf- paste your new input here; press return then ctrl/cmd+c to exit `cat’/save
If you view the file again it should have the new values. Now restart the fpm container. My troubleshooting process was going to be increasing max_children until the PHP loads without timing
out.
Thanks! This worked to update the config file. I’ve upgraded to 16 works, and here are the results on a few common areas
Homepage: 23s
/wp-login.php: 1m 12s (this page is forcibly redirected
Logging in to /wp-admin: 3m (just under)
Loading /wp-admin/edit.php: 53s
So, vast improvements given that pages actually load - but it’s still unworkably slow.
No obvious misnomers in the access or error logs.
Kevin
(Kevin)
16
So it’s like PHP processing is being very inefficient. Did the fresh WordPress installation speeds improve at all? I will see if there are any more configuration tweaks that may help.
You can try using a plugin like Query Monitor to get more details on where the slowdowns are. You can also try changing the PHP version (just remember you would have to edit the php configuration again for that specific version)
I think we have a good amount of troubleshooting info here so I’ll share all of our findings with our developers and get their advice.
Sure - here are a few results from query monitor
User accessible dashboard (non wp-admin)
wp-admin index
wp-admin posts edit page
wp-admin editing an individual post
1 Like
Kevin
(Kevin)
18
That’s interesting. Can you get more info on these HTTP calls? I’m wondering why each on is adding almost exactly 10 seconds each
Since they are HTTP calls you should be able to see them in the Network Tab of DevConsole. What does your waterfall look like on the slowest page when sorted from slowest-quickest:
Kevin
(Kevin)
20
Huh, admin-ajax.php loading normally is unexpected. If you go back to query monitor what are those HTTP API Calls? I thought we would be able to see them in DevConsole but I guess not. For example, when I go to edit a post, I don’t get any HTTP API Calls. Do you have a plugin running in wp-admin making slow API calls there? I’m guessing it could be related to whatever those “sync” and “retry” fetches are doing.
