Bug Absolutely abysmal performance

[rudy1220]

We had extremely high hopes for this addon but it absolutely crippled our database. We have roughly 8 million 'thanks' in our system and upon activating this product, we went from 0% CPU usage on our DB server to 25% nearly instantly. Eventually the connections piled up and the database server started refusing connections resulting in downtime for our users.

We've had to revert back to using Abe's thanks hack. It isn't perfect, but at least it runs without killing our website.

Our database server is a 24 core machine with 64 GB of RAM. It should have been able to easily handle this small number of thanks contained in our database. To say that we're disappointed is a huge understatement.

We applied the new index mentioned in another thread regarding performance and it did help, but not nearly enough.

Are there any plans to make this system work better with larger boards? If not, it is completely and totally useless to us and we are stuck with Abe's software.

Your input would be appreciated.

 

[Fillip H.]

Please provide the APTL-related queries from your MySQL Slow Queries log. Without this information I will be unable to assist you.

 

[rudy1220]

That isn't a satisfactory answer. You should already know where your performance bottlenecks are in YOUR software. It is not up to us to diagnose and troubleshoot it for you.

We did not capture any slow queries with 'thanks' in the string (Slow query is > 5 seconds) but that doesn't change the fact that our CPU usage went through the roof on our database server as soon as this was activated. We couldn't even keep the software running long enough to do any sort of troubleshooting.

We have spent a lot of money with you, and I would hope that we could receive better support than "If you don't provide slow queries, we're not helping". Slow queries or no, it crashed our database server almost immediately. If you can't / won't work toward a solution, I'd really like to request a refund of the fees we paid for the professional edition, as it's of absolutely 0 use to us in its current state.

 

[Fillip H.]

You should already know where your performance bottlenecks are in YOUR software. It is not up to us to diagnose and troubleshoot it for you.

We don't have access to a large test forum with several hundred concurrent users and 8 million Thanks entries. For that reason, if a specific forum is having an issue with our mod, we request their assistance in figuring out what part of the mod is causing issues for them.

For instance, is there any one post with a very large amount of Thanks clicks? You can find this out by running the following query:

SELECT COUNT(*) AS numthanks, contentid FROM vb_dbtech_thanks_entry GROUP BY contenttype, contentid ORDER BY numthanks DESC

(replace vb_ with your table prefix)

If there's no obvious candidates, the following query might work to find out if there's any one thread with a very large amount of Thanks clicks:

SELECT COUNT(*) AS numthanks, threadid
FROM vb_dbtech_thanks_entry AS entry
LEFT JOIN vb_post AS post ON(post.postid = entry.contentid)
WHERE contenttype = 'post'
GROUP BY threadid
ORDER BY numthanks DESC

(replace vb_ with your table prefix)

We did not capture any slow queries with 'thanks' in the string (Slow query is > 5 seconds) but that doesn't change the fact that our CPU usage went through the roof on our database server as soon as this was activated. We couldn't even keep the software running long enough to do any sort of troubleshooting.

How many concurrent users were there on the forums at the time?

 

[rudy1220]

We don't have access to a large test forum with several hundred concurrent users and 8 million Thanks entries. For that reason, if a specific forum is having an issue with our mod, we request their assistance in figuring out what part of the mod is causing issues for them.

For instance, is there any one post with a very large amount of Thanks clicks? You can find this out by running the following query:

SELECT COUNT(*) AS numthanks, contentid FROM vb_dbtech_thanks_entry GROUP BY contenttype, contentid ORDER BY numthanks DESC

(replace vb_ with your table prefix)

Left query running for 10 minutes before giving up on it.

If there's no obvious candidates, the following query might work to find out if there's any one thread with a very large amount of Thanks clicks:

SELECT COUNT(*) AS numthanks, threadid
FROM vb_dbtech_thanks_entry AS entry
LEFT JOIN vb_post AS post ON(post.postid = entry.contentid)
WHERE contenttype = 'post'
GROUP BY threadid
ORDER BY numthanks DESC

(replace vb_ with your table prefix)

Since our post table is MyISAM, I'm not going to run this query for fear of locking it up while users are trying to use the site.

How many concurrent users were there on the forums at the time?

200 users; 1800 guests;

 

[Fillip H.]

I guess I'll just have to insert a random amount of rows for posts in a thread then, and hope I can replicate it.

It would have been a lot more helpful to receive the actual values, though

 

[rudy1220]

I understand. We just have a lot of changes and acquisitions going on right now and 10 minutes was about all I could wait to run that query. We aren't going to end up using this mod on our sites, at least not right now. It's just too big of a performance drop compared to Abe's. When we have more time, I'll try to run those queries again to see what results we get.