Skip Navigation

[Resolved] Site slow / down after migration

This support ticket is created 3 years, 6 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 - - 9:00 – 13:00
14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 - - 14:00 – 18:00

Supporter timezone: Africa/Casablanca (GMT+01:00)

This topic contains 12 replies, has 2 voices.

Last updated by Jamal 3 years, 6 months ago.

Assisted by: Jamal.

Author
Posts
#2215509

Hi Team,

I am trying to go live with a website I relaunched and migrated. This site was heavily relying on Views in the past. I replaced to the old views with new Toolset Block Views.

As I am relaunching eight websites which are all quite similar, I've been using the Toolset Module Manager in order to migrate views and taxonomy archives from one site to the other.

The very odd thing is that even after migration from the staging domain (staging.expample.tld) to the final domain (www.example.tld), everything is looking good in the first place. I am checking this by modyfing my hosts file and pointing my machine's DNS and browser to the new server directly (ignoring the public DNS). I can then browse through the entire new site, no errors.

But: Then, as soon as I change the public DNS and send real traffic to the new website, it only takes some minutes, and everything is slowing down.

I've changed PHP settings and limits repeatedly. The ressources on this server are more than sufficient, it's a dedicated server with lots of resources. More than that, I've built an entirely new server (Ubuntu based Plesk on AWS Lightsail) and installed a copy of the site in question on that server. Same problem, same behavior.

Fun fact: I even performed a load test (with loader.io) – sending 1.000 sessions to the home URL within one minute is no problem. No errors (remark: "no errors" only within the timeframe of some minutes – before the site is getting slow and then producing 524 timeouts).

I am quite sure this has to be related to Toolset Blocks because I am getting a real flood of PHP notices like this one:

PHP Notice: Trying to get property 'ID' of non-object in /var/www/vhosts/xxxx/httpdocs/wp-content/plugins/toolset-blocks/vendor/toolset/toolset-theme-settings/compatibility-modules/controllers/toolset-theme-integration-settings-front-end-controller.php on line 79

Remark: The debug info I provided is the one from the installation on the AWS test server which I mentioned.

Kind regards,

Bernhard

#2215597

Hello Bernhard and thank you for contacting Toolset Support.

Does the home page use nested views? If yes, how many levels of nesting?
Does the view use the Toolset cache? Is Toolset cache used for any other views?
Can you share some server level stats for the period where you have run tests? This way, we can see what type of resources has been used much.

Would you allow us temporary access to your website to check it closely and run some tests? Your next reply will be private to let you share credentials safely. ** Make a database backup before sharing credentials. **

#2215927

Thank you for the credentials. Unfortunately, The Plesk UI does not give any statistics that might be relevant to our case.

I setup the domain mapping in my local hosts file and I was able to access the site on this server. The load time for the homepage is around 9s on my machine, and that's not good based on my internet speed and the server resources(Large memory).

I installed Query Monitor and it reveals some slow queries that we may be able to optimize, but we'll need to run some tests in order to isolate the issues and fix their root causes.

Please perform the following tests on the homepage with the following configurations:
1. With Toolset + The current theme + All other plugins.
2. Without Toolset + The current theme + All other plugins.
3. With Toolset + The current theme + Without all other plugins.
4. Without Toolset + The current theme + Without all other plugins.
5. With Toolset + A default theme(2021) + With all other plugins.
6. Without Toolset + A default theme(2021) + Without all other plugins.

Please record Query Monitor results in a similar case to:
************************************************
1. +/- Toolset +- Theme +- All plugins
************************************************
Page generation time: xxx
Peak memory usage: xxx
Database query time: xxx
Number of queries: xxx

These tests are rather general performance tests/benchmarking than a test targeted to this unique issue(Sever gets slower after a few minutes of load tests).
For that, we'll need some kind of server statistics. Unfortunately I could not find similar reports on Plesk then these discussed on this article hidden link
If you can find them, please share the period of time where you have run the load tests and the few minutes after it(when the server gets slow)

#2216033

Hi Jamal,

I think the Plesk KB article refers to an older version. In Plesk Obsidian, do you see the "Monitoring" in the menu to the left? There, you'll find CPU usage, etc. It is also possible to login via SSH with your user.

Hope this is a first step to move forward. I will be performing the benachmarks and get back to you.

Meanwhile, on that staging, please feel free to deactivate plugins, switch themes, etc., as per your needs. That's okay from my side!

Kind regards,

Bernhard

P.S. – I am also getting this on other sites which are already live –

PHP Notice: Trying to get property 'ID' of non-object in /var/www/vhosts/xxxx/httpdocs/wp-content/plugins/toolset-blocks/vendor/toolset/toolset-theme-settings/compatibility-modules/controllers/toolset-theme-integration-settings-front-end-controller.php on line 79

These notices are filling the server's log files very quickly. They are coming in on a per-second-base.

#2216087

I don't find the Monitoring page on Plesk. This is what I get

Regarding the PHP notices, these are the notices that get repeated:

[06-Nov-2021 15:29:13 UTC] PHP Notice:  Trying to get property 'post_type' of non-object in /var/www/vhosts/e-commerce-magazin.de/httpdocs/wp-content/plugins/toolset-blocks/application/controllers/compatibility/wpa-block-editor/wpa-block-editor.php on line 220
[06-Nov-2021 15:29:13 UTC] PHP Notice:  Trying to get property 'ID' of non-object in /var/www/vhosts/e-commerce-magazin.de/httpdocs/wp-content/plugins/toolset-blocks/vendor/toolset/toolset-theme-settings/compatibility-modules/controllers/toolset-theme-integration-settings-front-end-controller.php on line 79

I can check those later and see what is triggering them, and how we could fix them. But, I'll need to take a copy of your website for that matter. Let's first see what results we'll get from the tests that you will run.

#2216499

Hi Jamal,

I've now performed these tests:

hidden link

An additional error I found in the console was getimagesize(hidden link..../%5Btb-dynamic%20provider=): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found

Kind regards,

Bernhard

#2216609

Hi Jamal,

I have implemented New Relic Monitoring for this server and WordPress instance. There are quite interesting and detailed insights availabe – if of any use, I can give you access.

Kind regards,

Bernhard

#2216861

Hello Bernhard, and thank you for the provided information.

Performance debugging is a hard task. And any additional information can help us analyze the situation better. The New Relic reports will, for sure, help us. I assume that you are talking about the server monitoring(CPU, Memory, Disk IO, etc.) right? It would be better to check around the period of the load test.

#2217429

Hi Jamal,

I can give you access to the New Relic dashboard. How can I securely share these credentials?

Important: The site you have access to is now live, so please don't change anything vital there. If you need access to a playground, I can still offer the AWS version of the site which is more or less identical.

Kind regards,

Bernhard

#2217445

Hello Bernhard, sure, I won't change anything. And if I need a staging site, I'll let you know.

I am setting your next reply to be private to let you share credentials to New Relic's dashboard.

#2217507

Thank you Bernhard, the statistics from New Relic are interesting. But, I must confess I could not find anything that may explain performance issues.
The statistics from your last tests with Query Monitor did not give anything relevant to this case.

So I visited the live site(104.26.6.241) and went through all the page in the navigation menu. The website is very responsive. Most pages are loading in less than 1s. Some pages(homepage included) may load between 1-4s in the first visit, but every subsequent visit loads in less than 1s(probably thanks to caching). One page has loaded in 10s the first time, then, all subsequent visits loaded in less than 1s.

In general, I would say that the site is very responsive and loads very fast. Without more information about the performance issue, or without knowing something that could trigger it(steps to follow to reproduce a performance issue), I am afraid I remain helpless.

I'll remain at your disposal.

#2217559

Hi Jamal,

I see what you mean – seems that one of my measures contributed to the site getting faster. Because if you'd changed anything relevant, you had let me know ...

Still there are some issues. E.g. I am getting several 404 errors per minute:

Error <the servers own IPV6 address> 404 GET /%5Btb-dynamic%20provider= HTTP/1.1

Edit: I can also see this on the source code of the home page:

<meta property="og:image" content="hidden link" />
<meta property="og:type" content="website" />
<meta name="twitter:card" content="summary">
<meta name="twitter:title" content="Startseite" />
<meta name="twitter:description" content="" />
<meta name="twitter:image" content="hidden link" />

Do you have idea where this could have its root?

Kind regards,

Bernhard

#2217617

If we decode this URI "%5Btb-dynamic%20provider=" we get:

[tb-dynamic provider=

This shortcode is used internally by the Gutenberg editor for the Toolset Blocks, in order to get the data from Toolset elements(fields, taxonomies, etc.). I would suspect that these errors happen in a window that has the Gutenberg editor open(page, post, content template, etc.)

The social tags are most probably generated by YoastSEO:

<meta property="og:image" content="<em><u>hidden link</u></em>" />
<meta name="twitter:image" content="<em><u>hidden link</u></em>" />

I think that YoastSEO search for the first image in a page content, or the featured image to render these tags. I assume that it has scanned the homepage content and the first image that it encounters in a dynamic image from Toolset, inside the first view.

I suggest one of the following solutions:
- Add a featured image to the homepage.
- Add an image at the top of the page content, you can hide it using a custom CSS class or using the blocks responsive utilities.
- Add Images to the YoastSEO settings for the page, check this screenshot hidden link

I'll remain at your disposal.