Helo. I've just added toolset to my site and it's killing by CPU. There is a very simple query with a page title and a featured image and less than 12 results, but I'm hitting maximum CPU all the time and site is really slow
[Tue Sep 08 11:38:38.681666 2020] [lsapi:error] [pid 32559:tid 47230983169792] [client 2.30.124.63:64067] [host forreslocal.com] Connect to backend rejected on sending request(GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=post&preview-post-id=33457&_locale=user HTTP/2.0); uri(/index.php?post-type=post&preview-post-id=33457&_locale=user), check docs.cloudlinux.com/mod_lsapi_troubleshooting.html, referer: forreslocal.com/wp-admin/post.php?post=57&action=edit
My host reports:
According to docs.cloudlinux.com/cloudlinux_os_components/#troubleshooting-4 the PHP service (LSPHP daemon) rejects additional connections when too many are being served already.
Perhaps the toolset creates a lot of PHP requests at ones.
Hi,
Thank you for sharing these details.
The first thing that I'll recommend would be to see if the hosting server meets the minimum WordPress and Toolset requirements:
https://wordpress.org/about/requirements/
https://toolset.com/toolset-requirements/
To troubleshoot this in detail, I'll suggest the following next steps:
1. Please make sure that WordPress, active theme, and plugins are all updated to the latest versions.
2. It would be interesting to test this with all non-Toolset plugins disabled and a default theme like Twenty Twenty.
If it's fixed, you can start adding the disabled items, one-by-one, to narrow down to a possible conflicting one.
3. In case the issue still persists, I'll request you to share a clone/snapshot of the website so that it can be tested on a different server.
( ref: https://toolset.com/faq/provide-supporters-copy-site/ )
Please let me know how it goes and I've set your next reply as private.
regards,
Waqar
I am not able to create a duplicator package.
Thank you for sharing the admin access.
The Toolset plugins do load their own static resources (e.g. CSS and JS files) and helper functions in the background, which is why on a website with a large database, jump from 1 to 6 seconds would be somewhat expected.
( espcially if you're also using filters to reach to specific results )
Is there any particular page that I should be checking and do I have your permission to download a duplicator package from the website (if needed)?
Home page,
it loads the most recent 10 blog posts from a selection of 420, and all it displays is post title and featured image, I really don’t think that should put so much stress on the system.
I installed duplicator but it errors, please feel free to try
Thank you for waiting.
I managed to create a duplicator package of your website, by excluding the "uploads" folder.
Your website's homepage currently has two separate post views and it seems to perform really well in terms of page loading times.
For non-logged in visitors, it loads in under 4 seconds and for logged-in admins, it loads under 7 seconds.
( note: For logged-in admins, the page speed difference is expected as WordPress, themes, and plugins, all are performing several administrative tasks in the background )
These loading times are really encouraging, especially considering the fact that no caching or optimization plugin is enabled, at the moment. Once you're done with the development, you can enable caching and minification and you'll get even better results.
You'll see the same results while testing through the testing tools like "GTmetrix" and "Pingdom":
hidden link
hidden link
Is it possible that when you noticed the spike in the CPU usage, some maintenance or updates task was running in the background?
It does look a little faster, but I will retry and see, but if adding a post is a maintenance task, I can't afford for the site to go down every time I add a post. This doesn't happen on any other site I have with toolset.
A loading time of 7 seconds is NOT encouraging by any measure. and it looks like toolset is adding 35 http requests , which seems insane. It's loading in under 3 now, so I'll take that as happy medium and see if it happens again. May I keep the ticket open in case I need to come back to you?
Thanks for the update and glad that there is progress.
Although I don't have a time estimate to share at this time, we do have some internal tickets to improve how Toolset plugins load static resources. That should also help in lowering the number of HTTP requests, out-of-the-box.
Meanwhile, you can always minify and combine scripts and CSS files, through a third-party cache and optimization plugin of your choice and these requests would reduce.
This ticket would stay open for the next couple of weeks and you're welcome to share any update or follow-up questions.
Note: even if you've something related to share after the ticket is closed, you can start a new one and just include this ticket's URL in it and we'll know that it is a follow-up.
