Same here. We are running TagDiv on three high volume sites – and running into tons of issues despite putting in a ton of caching. We know it’s the db queries, and which queries, but without hacking the theme, we are looking at alternatives. Any thoughts on that newly popular jnews?

They hid most of the previous comments on this thread. Instead of fixing it, they want to sweep it under the rug, as it were.

So you guys hid all of the comment posts? Seems like an irrational move. We just purchased a different theme from a different provider for three more web projects, and for a fourth, we’ll likely move them off of the old newspaper version to an entirely different theme…

Uhh…you must be a CSM and not a dev…that’s the same query over and over again, not many different queries, but okay.

Here is an example of the queries that cause the problem:

| 147619 | [hostname]_wp_swlbr | localhost:33558 | [hostname]_v2 | Query | 6 | executing | SELECT SQL_CALC_FOUND_ROWS NOS3G_posts.ID
FROM NOS3G_posts INNER JOIN NOS3G_postmeta ON ( NOS |
| 147620 | [hostname]_wp_swlbr | localhost:33560 | [hostname]_v2 | Query | 1 | executing | SELECT SQL_CALC_FOUND_ROWS NOS3G_posts.ID
FROM NOS3G_posts INNER JOIN NOS3G_postmeta ON ( NOS |
| 147621 | [hostname]_wp_swlbr | localhost:33564 | [hostname]_v2 | Query | 12 | executing | SELECT SQL_CALC_FOUND_ROWS NOS3G_posts.ID
FROM NOS3G_posts INNER JOIN NOS3G_postmeta ON ( NOS |
| 147623 | [hostname]_wp_swlbr | localhost:33572 | [hostname]_v2 | Query | 9 | executing | SELECT SQL_CALC_FOUND_ROWS NOS3G_posts.ID
FROM NOS3G_posts INNER JOIN NOS3G_postmeta ON ( NOS |
| 147626 | [hostname]_wp_swlbr | localhost:33592 | [hostname]_v2 | Sleep | 0 | | NULL |
| 147631 | [hostname]_wp_swlbr | localhost:33636 | [hostname]_v2 | Query | 5 | executing | SELECT SQL_CALC_FOUND_ROWS NOS3G_posts.ID
FROM NOS3G_posts INNER JOIN NOS3G_postmeta ON ( NOS |

The database is not in need of repair – the problem is purely one of a lack of caching – and a lack of forethought by the dev team.

Every single page request is generating a db request because the db won’t rely on the previous returned value in the db cache because it changes after every new pageview. Might not seem like a big deal, but when you get spikes of hundreds of visitors per second, even with a beefed up server, it slows mySQL, and the apache processes stack up waiting for a mySQL response.

It’s not rocket science. If the returned values for the block were set to only refresh every nth minutes, then it wouldn’t generate piles of complex queries – indeed, the query cannot be efficient, because it is checking pageviews across all posts for a given time-frame, which is not indexed – so even our tiny new site, which does 80k+ pageviews/day and has about 2k posts dies despite having an 8-core machine with 32gb of ram running with memcached on litespeed on PHP8.

Turning that filter off dropped average usage to consistently under 5% cpu usage, instead of 200% with 503 errors.

FFS- I can share the queries that are the cause – this isn’t some shot in the dark or loose assertion – the server was killed by this feature and traffic suffered, and we know because we checked, and could see the join queries that were responsible for the snowballing server load.

• This reply was modified 3 years by dmkeene.
• This reply was modified 3 years by dmkeene.

Interesting Archerix. I’m wondering if using the jetpack+stats module limits the joins being done in mysql. We may need to test that at some point. Thanks.

Seems odd to me that they put so much dev time into the front-end editor, but didn’t think out performance at scale. Heck, our site is tiny, but still does 60-80k pageviews a day…I guess we’ll have to rethink using tagdiv products for other projects.

Same for us. When traffic spikes on our site – usually we get spikes of a couple of hundred visitors per second – it kills the site with 503 errors – all because the most popular filter setting is generating piles of db requests.

This feature should have some settings to it that reduce the load on the db server – notably it should cache the result and refresh it every minute – which would mean a single db INNER JOIN per minutes, instead of hundreds. That seems like it would be the best solution…

Processing even one of these queries per second will kill mySQL and burn up CPU – this is lazy work here.