Extreme CPU usage and slow site after permalink update

Not going to be able to tell much with it in maintenance mode, to be honest, and even then, without being able to see what you have going on in the admin and possibly try out some debugging tools, I won’t be able to tell too much.

That said, at least for the moment, have you checked any error logs that your hosting has configured for you? They may be able to tell you something.

Possible that there’s infinite redirects that aren’t quickly timing out.

I’d be willing to give you full admin access if that is helping? Please tell me how I can transmit this info privately.

Hosting support created a log file full of stuff that they apparently gathered, but I don’t really understand what to look for, it’s huge.

Located here: https://ginkgo-gaming.com/strace.txt

It really seems as if there would be a lot of redirects. Strange thing is, it’s the second time that this has been happening, different template and different host. But it happened at exactly the same point, after installing badgeos.

michael @ webdevstudios . com will reach me for a user login etc.

I have no idea how to parse that stack trace either. None of it is providing information that I could use.

I just sent you a mail containing login information.

Thanks for assisting me! Merry Christmas!

Will try and check on it soon

I’m not managing to notice any sort of slowdown or 504 errors. I am using the installed Query Monitor plugin available, and everything red showing up or slow things aren’t associated with BadgeOS.

If you have specific actions to take to help trigger, that’d help, otherwise I’m not sure there’s anything going on.

Try refreshing the site 2 times and you will see a massive slowdown. The more you click around on it, the slower it gets and cpu usage increases tenfold.

The query monitor does not display redirect issues badgeos created.
Script execution times are all good, and thats why you wont see any association with badgeos.

Redirect issues shouldn’t be coming from BadgeOS because we don’t have any in the frontend.

You have a lot of AJAX requests going on, and each one is slow, at least 4000ms each, and most are not from BadgeOS as well.

Even with both BadgeOS plugins deactivated, it wasn’t really all that snappy from my observations. It feels like you just have a lot going on with loading of scripts and styles and browser events.

The only real place I can see any BadgeOS usage on the frontend would be the dashboard and the post type registration needed to register the associated post types for Badgeos. I just can’t think of what would be causing slowness from us, and I don’t have any great information or way to try and deduce what the source is here.

But it happened right after working with BadgeOS. Was getting 404 errors on single badge display, I then updated permalinks, which essentially broke the site.

All AJAX requests were very fast before BadgeOS, and I didn’t change anything..

What is more unsettling is that even restoring a backup from a day where all was good, it’s still broken.

Permalinks shouldn’t be dictated at all by our plugin. Given that I’m seeing /%postid%/ in all the permalinks even with BadgeOS disabled says something with your current settings aren’t accurate.

All the ajax requests were 4000-5000ms each without BadgeOS with my testing last night.

Not saying definitively it’s not us, I just have nothing I can go on to say it for sure is us.

I understand that BadgeOS doesnt dictate permalinks, but I stumbled across a forum post saying that if 404 errors would happen on single badge display pages, just refreshing the permalinks would help.. well it did but at the sime time the site begun to slow down to a crawl.

Could it be that there is some sort of database conflict with other plugins? I remember that I had the issue with creatingg the ‘badge’ achievement category. that page would not work, no matter what I did, but changing the singular name to badges did solve the problem. Maybe something wrecked havoc in the database?

Even non-BadgeOS single post urls are having issues right now, that’s the thing. It’s not tied to BadgeOS, it’s the site’s settings.

Category slugs shouldn’t directly conflict with post type slugs at all, though I could see possibilities with queries if you have site.com/badge/badge/badge-1/ as a URL.

“badge” is the slug for the default post type we create to help set things up, if I recall right, so using that as a page slug as well would mix things up between the page and the post type archive.