Very slow loading Control Panel Home Page

[Sidane]

Every time I enter the Admin CP the homepage (right frame) takes an age to load. At least 2 minutes, if not longer.

The top frame and left navigation frame load instantly. Is it because that page is checking various settings - like server load, database usage, post/topic count for today etc?

Has anyone else encountered this problem?

I'd like to know what the cause of this might be and if there is a possible solution?

[the Sandman]

Have you tried disabling the Quick Stats?

[eva01]

do you have any hacks installed for the admincp index, like the "who's online on admincp"

that may make it slower as well

[Sidane]

No admincp hacks installed. I turned of Quick Stats in admincp and it still took over a minute to load the homepage

But I just noticed when trying it in FireFox that the status bar said "Waiting for version.vbulletin.com". Then the top version bar loaded followed by the main frame.

I tried it again and after about a minute the homepage with the Quick Admin Links loaded, but the top version frame didn't load at all.

Looks like it could be the version check slowing things down.....any suggestions?

[davrob]

This may only be a coincidence, but, when the server here at vB is slow, or offline for some reason, my main control panel page is slow. That's the only time really, unless there is a known server issue on my part.

It may very well be the "version check".

David

[TheMusicMan]

I notice the same thing on my forums to be honest. At first I thought it might be something to do with my webhost, but all other sites open fine. I checked on several of my vB installations and it seems that it may be something to do with the vB License lookup on that page as if I click on any other part of the AdminCP, it goes to that section immediately.

This has been happening for me for a few days now - in fact ever since I upgraded to 306.

[poolking]

You will probably find it is trying to "call home" to determine the latest version of vbulletin to display the "Latest Version Available" at the top of the admin cp. When you see the admin cp loading you will see a url in the status bar "version.vbulletin.com".

[MJM]

I checked on several of my vB installations and it seems that it may be something to do with the vB License lookup on that page as if I click on any other part of the AdminCP, it goes to that section immediately.
This has been happening for me for a few days now - in fact ever since I upgraded to 306.

Same here, and it's getting worse.

Please vB, fix this. If this is caused by above quote, it is an insult to my integrity every time I have to wait for confirmation that I am a license owner, have always paid my yearly upgrade/member access fees and copyright removals.

Mark

[Steve Machol]

This is caused by a routing problem between your server and the vB server. There isn't anything we can do about this I'm afraid.

[MJM]

I use another product under same principles that functions with no delay.
The appearance that vB/routing is in some way connecting to my quick stats is disconcerting.

Having to wait everytime I go to admin cp if I wish to view this info is what makes `Quick Stats' not-so-quick and a daily annoyance.

I just can't believe that this company would let something like this undermine what is otherwise an incredible product .

Call it blind faith, but I believe vB can fix it.

Mark
...using no hacks that would affect this

[Steve Machol]

'Quick Stats' is not a connection problem with vB. That's a different issue. This is dependent on the speed that the server can complie and return this info. It's slow on my server as well - but only for my main forums. It is very quick for my test forum that has only a few posts on it.

It may be possible to optimize that code somewhat, but based on my limited coding knowledge I believe this is more of a server issue.

I'll see if one of the Developers can take a look at this.

[MJM]

Thanks much for claryfying!
Will leave this in the able hands of the developers

Mark

[Mike Sullivan]

Having to wait everytime I go to admin cp if I wish to view this info is what makes `Quick Stats' not-so-quick and a daily annoyance.

Well, if you want to speed it up, disk space is the trade off. In my opinion, it's not worth adding these indexes solely for just this, but if it is for you, go for it.

For the quick stats, take a look at some of the queries of note:

 $attach = $DB_site->query_first("SELECT SUM(filesize) AS size FROM " . TABLE_PREFIX . "attachment");
$avatar = $DB_site->query_first("SELECT SUM(filesize) AS size FROM " . TABLE_PREFIX . "customavatar");
$profile = $DB_site->query_first("SELECT SUM(filesize) AS size FROM " . TABLE_PREFIX . "customprofilepic");
$newusers = $DB_site->query_first("SELECT COUNT(*) AS count FROM " . TABLE_PREFIX . "user WHERE joindate >= $starttime");
$newthreads = $DB_site->query_first("SELECT COUNT(*) AS count FROM " . TABLE_PREFIX . "thread WHERE dateline >= $starttime");
$newposts = $DB_site->query_first("SELECT COUNT(*) AS count FROM " . TABLE_PREFIX . "post WHERE dateline >= $starttime");
$users = $DB_site->query_first("SELECT COUNT(*) AS count FROM " . TABLE_PREFIX . "user WHERE lastactivity >= $starttime");
 
// ... 
 
$attachcount = $DB_site->query_first("
SELECT COUNT(*) AS count
FROM " . TABLE_PREFIX . "attachment AS attachment
INNER JOIN " . TABLE_PREFIX . "post USING (postid)
WHERE attachment.visible = 0
");
$eventcount = $DB_site->query_first("SELECT COUNT(*) AS count FROM " . TABLE_PREFIX . "event WHERE visible = 0");

Those are all going to be full table scans.

You can add indexes on:

• user: joindate, lastactivity (as seperate, single column indexes)
• thread: dateline
• post: datline
• attachment: visible
• event: visible

You will see more speed increase but more disk usage the bigger the table is. (So post would probably bring your biggest increase.)

[MJM]

Sorry, I have now entered the world of the mysterious and unknown... will need to hand this over to someone more technically inclined.

For a site that has under a thousand members, a few doz posts a day, a few doz members a day visiting the site, a few dozen total viewers visiting the site at one time, with a couple thousand posts accumulated... in other words a very small but growing site... I would have thought that gathering whatever queries would be quick, in comparision to other larger sites...

so...
Q1.
Disk space should not be a problem in my case, right?
( edit: I still have plenty to use up at my site)

Well, if you want to speed it up, disk space is the trade off. In my opinion, it's not worth adding these indexes solely for just this, but if it is for you, go for it.

Q2.
Can you clarify? Is "not worth" in reference to "disk space tradeoff" only, or other things as well?

For larger sites how much disk space increase could one expect as a tradeoff?

Thanks,
Mark

[Mike Sullivan]

Sorry, I have now entered the world of the mysterious and unknown... will need to hand this over to someone more technically inclined.

You can add the indexes via phpMyAdmin.

For a site that has under a thousand members, a few doz posts a day, a few doz members a day visiting the site, a few dozen total viewers visiting the site at one time, with a couple thousand posts accumulated... in other words a very small but growing site... I would have thought that gathering whatever queries would be quick, in comparision to other larger sites...

The option is off be default, so most people won't see the quick stats. In an unscientific test, these forums took a good 25 seconds to load the quick stats. Even adding all those indexes isn't going to help the summing queries much. By their nature, they have to look at every record in the database.

Disk space should not be a problem in my case, right?

Probably not.

Can you clarify? Is "not worth" in reference to "disk space tradeoff" only, or other things as well?

Primarily in terms of disk space. Though I don't think it's worth adding an index for a single query that isn't run often. If it's a single query when viewing a thread, that's clearly different.

That's just my opinion though.

For larger sites how much disk space increase could one expect as a tradeoff?

I don't have a number of hand, but it would likely be some where around (if the column you're adding an index to is an int) 8 * (number of rows) bytes.