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)
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?
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
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:
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:
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?
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
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.
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.
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.
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:
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.
