[GitHub Bug #895] Performance Tuning

hbf

I seem to have encountered a performance issue related to some of the content on the user profile page. Most attempts to load my profile result in a time-out

Fatal error: Maximum execution time of 30 seconds exceeded in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\library\database\class.database.php on line 279

This is pretty odd, since everything else on the forum seems to move pretty quickly. I'm sure it has something to do with the shear volume of notifications and comments in the feed. I'm wondering two things:

1. Is there something I should be doing to improve the performance of the tables associated with this information

2. Is there a way to expunge the glut of notifications from my queue?

thanks

Todd

You can use the following config to remove activities from your profile:

$Configuration['Garden']['Profile']['ShowActivities'] = FALSE;

422

Ctrl + f5 pmsl

Or via dos , deltree:all .

No idea mate, perhaps post your php.ini

x00

what version of vanilla do you have? the activity table was not correctly indexed before.

UnderDog

These 2 problems are going to be for the vanillawiki, once we figured some things out :-)

hbf said: 2. Is there a way to expunge the glut of notifications from my queue?

aha! Either it should be in Vanilla 2.1x OR make a plugin, hehe :-P

hbf

My forum is currently running 2.0.18

I hadn't seen any performance or functionality improvements in any of the latest minor builds so I havent upgraded.

Where did the indexing fix come in?

I'm not opposed to writing a plugin, but if 2.1 will be released a month or two after i finish i dont think its worth the effort.

If it would help i can post the ini file. I'm sure i could extend the timeout, but thats not really what im after... if it takes more tham 30sec to return a page i still have a performance issue.

UnderDog

I'll figure out an adjustment you can make which points out the SQL query that takes so long. You indeed have a performance issue and it can be solved in a number of ways.

I hope you can install Vanilla 2.1 (daredevil version) on a local PC.

Export the structure of your Vanilla 2.0.18 (please upgrade to 2.0.18.4 please) Export the structure of your Vanilla 2.1 (daredevil)

We'll figure out what to do next once you're up for it.

x00

yep activity is not properly indexed.

Gillingham

I've documented a lot of the slowdowns here

Throwing more memory at it so it can store all the temp tables in memory can help alleviate it.

You can also alleviate part of it by disabling activity access and links the the activity pages.

UnderDog

Good bugreport Gillingham, it came from the following Forum Url: http://vanillaforums.org/discussion/15881/profileactivity-pages-extremely-slow (for more information and hopefully some solutions)

I know that in Vanilla 2.1 the Activity Table(s) are properly indexed. If you cannot wait that long or for the real solution for Gillingham's bug report, let's see if we can walk through the sourcecode and solve some of it... (plugins)

In that case we need to know from @Todd if in 2.1 we can control which activities show up in the Activity tab of the users, or can we control other part of activities?

By the way ... my code modification was to show how long a query would take and which query it was. The same can be achieved by (documentation ;-) ) turning on the debug mode. By looking at the queries (or Gillingham's queries) some of the problems can be analyzed and taken care of.

So if that is enough info, I won't have to show my code modification :-)

x00

this issue is 11 months old.

UnderDog

x00 said: this issue is 11 months old.

I have no smart response for that one, so I'll see if I can ask something instead: Is there some way in gitHub to see any source commits (SVN guy here) that belong to bug #895? I think that some commits have been made, but they're waiting to release 2.1 for this bug to be resolved

Todd

In 2.1 the activities are filtered by one column which is indexed. Either
NotifyUserID or ActivityUserID. If an activity makes sense in more than one
place. Say the activity should notify a user and it should be public then
it is inserted twice.

If a user changes their notification preferences then it affects what
notifications they get in the future. Notifications that aren't wanted are
never inserted into the activity table in the first place.

If you want to speed up your activity page pre 2.1 I recommend culling the
records to a size that queries faster. Most activities and notifications
are transient in nature and don't need to be kept around forever.

hbf

UnderDog said: I'll figure out an adjustment you can make which points out the SQL query that takes so long. You indeed have a performance issue and it can be solved in a number of ways.

I hope you can install Vanilla 2.1 (daredevil version) on a local PC.

Export the structure of your Vanilla 2.0.18 (please upgrade to 2.0.18.4 please) Export the structure of your Vanilla 2.1 (daredevil)

We'll figure out what to do next once you're up for it.

I'll try to set up a dev environment with 2.1 tonight, and i'll do a test upgrade to 18.4 also.

hbf

Todd said: In 2.1 the activities are filtered by one column which is indexed. Either NotifyUserID or ActivityUserID. If an activity makes sense in more than one place. Say the activity should notify a user and it should be public then it is inserted twice.

If a user changes their notification preferences then it affects what notifications they get in the future. Notifications that aren't wanted are never inserted into the activity table in the first place.

If you want to speed up your activity page pre 2.1 I recommend culling the records to a size that queries faster. Most activities and notifications are transient in nature and don't need to be kept around forever.

i don't actually think anyone uses the activities notification on my site, i would be happy to just strip it out for the time being.

hbf

Interestingly enough it seems to be working well now. Very responsive. Im thinking mysql cleaned up something on a recent restart.