Re: Performance Issues
We've checked your site's performance issues once more. Our system engineers have looked into the public infrastructure where your site is hosted, they checked your site's server and your site's server container. As mentioned previously, we do see a larger spike in CPU usage at around 3pm UTC / 7am your time. Our team looked into possible reasons here and as we mentioned earlier in the conversation the main thing that stood out is a very high amount of traffic going to the following wpdiscuz wp-json URL:
/wp-json/wpdiscuz/v1/update?referer=
We did check the traffic specifically, I checked if any bot-like activity is visible there. We did however not find any suspicious traffic so far. This does not mean that this is not necessarily the case as sophisticated bots can definitely camouflage very well but from the way the URLs are looking, there's just no concrete evidence in that direction. If you or your team do however see any indicators for that, we will of course check further.
Another important point about these wpdiscuz URLs is that they are all bypassed from cache. Three things about this are important to understand:
- Bypassed (from cache) pages will load via PHP and MySQL directly. This means the server resources are impacted as the server-side cache is not serving that page.
- Due to the fact that you have WP-Cron running when any site is opened via PHP/MySQL with these requests, WP-Cron is also being run in the background. We do highly recommend to disable WP-Cron running this way and only let it run from the server-side cronjob. We do have an article about this here which I recommend you and your team check out.
- Due to PHP/MySQL being used in the initial request of said URL and in the requests made to WP-Cron, this results in very high PHP/MySQL usage which impacts the resources on the rest of your site which is causing the slowness you have experiences (specifically in WP-Admin where every page has to be uncached for WP-Admin to work properly.)
It seems you've enabled live update and your website was under DDoS attack, so you've got tons of live update request. Please navigate to Dashboard > wpDiscuz > Settings > Live Commenting and Notifications Tab, and configure following settings:
1. Disable the live update for non-authorized visitors and request by disabling the "Enable Live Update for Guests" option.
2. You can keep enabled the "Comment Bubble Live Update" option but disable "Live Update" option.
3. Increase the period of new comment checking requests, set 1 min or higher the "Update Comment List Every" option.
4. Delete all caches again.
Hi Tom,
At no point was there any evidence of a DDoS and Kinsta never indicated that either, so please let's not bring any unsubstantiated variables into the discussion.
Currently, we have disabled the WPDiscuz plugin and it is still making requests.
1. This was already disabled
2/3/4: None of this had any impact on the site.
As you can see in the conversation below, WPDiscuz is still making calls while we have disabled the plugin. Please provide instructions to stop the adverse impact on our website. Thanks.
***KINSTA TRANSCRIPT
There's still a flood of them hitting wp-json/wpdiscz/v1/update which is very odd.
Our site has been brought down for a week and our host has pointed to your plugin as the culprit and you can't even respond? Not a great look for your company.
Hello,
Did you finally resolve the issue? I can see a 2020 post highlighting on the same issue but WPDiscuz support are shifting back the blame to your host.
Was this ever resolved or is the "solution" to simply disable the live update function on sites that have cache?
I just enabled the live update and while my server didn't crash, the 404 errors were cramming the log files.
Seems like gVectors has a bug they need to address here and it would be nice to see it addressed as such rather than trying to blame the hosting company. Or at least a tacit acknowledgement that the live update feature is incompatible with server cache.
Best,
Kim
Wanted to add a screen shot of the code that is generating the 404 error we're seeing on our site that matches the above complaint: