Hello,
I have a trellis/bedrock site that is running very slowly (30s-1min page loads or timeout) locally, and sometimes throws a 504 Gateway Time-out, but this slowness issue and timeouts do not happen when I push to my production server.
I have provisioned the server several times, it’s using https, and a local cert, same database and files as production.
Any ideas on how to debug this?
Are you using WSL 1 or WSL 2? If so, you may want to consider moving the files to the *nix file system, the performance improvements are dramatic. I use a private GitLab instance to sync the code between my WSL 2 instance and normal windows repository.
I’m on a mac, not a windows machine.
Are you using Trellis (Vagrant) for local development on OS X?
When so, what share type are you using, NFS or CIFS?
I’ve got a multi-lingual e-commerce site that’s heavy on plugins (WPML, WooCommerce … in total ~50 plugins of all sorts), which appears similar to what you’ve described.
While not perfect, my “solution” on local is to activate only the plugins, which are necessary for development (so no stock management, shipping, etc that are only needed in production). This significantly improves loading times on local.
As the current approach works for me, it will have to wait until I get closer to the real problem and a real solution - if there is one.
Also, using an object cache, I use Redis + WP Redis can significantly speed up the site, even locally.
I don’t use a cache because I deploy to Kinsta, and they don’t allow cache plugins as they use their own.
I am still facing serious issues and it’s hindering my development with minute wait times and 504 Gateway Time-outs.
I have 27 plugins. All are required for the site to work properly.
I am new to WP development, but this is unacceptable.
Do I need to increase memory limits or something? Deactivating plugins isn’t acceptable. This doesn’t happen on deployed Kinsta servers.
What could be the issue? Is it with Trellis/Bedrock?
Hi @aunumever,
In /trellis/vagrant.default.yml how much vagrant_memory do you have set? Try increase it.
vagrant_memory: 8000 # in MB
Also, try add the following lines to /trellis/group_vars/all/main.yml
# https://discourse.roots.io/t/502-bad-gateway-error/9619/2
nginx_fastcgi_buffers: 8 16k
nginx_fastcgi_buffer_size: 16k
For my setup I also added nginx_fastcgi_read_timeout: 600s as I needed the long timeout temporarily.
I tried this, and although better, and no timeouts yet, it still takes 40 seconds to load a page. Any other suggestions?
I thought using vagrant would allow env’s to act the same, but there’s a large discrepancy in speed and load times comparing my local/prod servers.
The environment parity provided by Trellis only applies if you’re provisioning both your local development environment and your remote server with Trellis–if you’re deploying to Kinsta, you aren’t provisioning anything remote: Trellis is only acting as a deploy mechanism for your staging/production servers.
Additionally environment parity is about the environment being the same–i.e. the OS, the configuration of various system services, nginx setup, etc–not resource parity. Your local VM and your remote server are very likely to have different system resources which can affect performance in a variety of ways.
A local VM (I’m guessing on VirtualBox?) is almost always going to be slower, sometimes significantly so, than a remote production server. VirtualBox has to do a lot of negotiation with the host OS and that’s always going to cause speed issues–IME especially w/ filesystem access which can be a bottleneck. Although most web hosts are still technically running virtual machines, they’re running on a system that is using very different, much more optimized virtualization software and hardware that’s going to provide near-native performance for those virtualized machines. You and I are running consumer desktop machines, and VirtualBox has traded performance for (relative) ease of use.
In my experience, slow WordPress sites are frequently the result of a large number of database queries, or slow/badly-written database queries. WP_Query and the other functions that wrap it have the potential to generate on your behalf some very unpleasant queries (i.e. OR searches for multiple meta fields). The worse performance of a local environment due to virtualization may exacerbate this problem (plus Kinsta has probably tweaked their MySQL environment w/ caching, etc, in a way that results in significantly improved performance to what you might see locally). A plugin like Query Monitor might help you track down bad queries. Kinsta has also recently introduced a very helpful monitoring tool which provides some great feedback on your environment and its behavior. Even if you don’t see the same perf issues in production you’re still running the same queries so you might still get some useful information.
If your site is doing things that hit the filesystem more frequently than usual (i.e. you load a whole bunch of images from the media library) that could also cause a performance dip locally, since filesystem performance in VirtualBox is usually quite a bit worse than what you see on a production server. As always, checking your logs is a good place to look as well.
That seems like a lot of plugins. Even if they are all required for your site to work, you might have some debugging success by selectively turning them off and seeing if you noticed a marked improvement in performance. That could help you narrow down where the issue might be coming from. Even if “delete that plugin” won’t ultimately be a viable solution, you’ll know what’s causing the problem, which can give you a path to solving it or working around it.
If any of your PHP scripts are making remote requests (i.e. to REST endpoints or something) that’s another place to look for performance issues: If they’re having trouble reaching the URLs they want to hit it may be taking them a long time to fail, or if they’re pointing at URLs w/in your site they could be running into and exaggerating the virtualization perf issues described above, or simply failing because for some reason they’re looking for production-y URLs that now no longer exist.
I got near-production performance by using WSL 2 and cloning the site to the *nix/WSL system and using a REdis object cache.
This topic was automatically closed after 42 days. New replies are no longer allowed.