New forum software is very slow

G

Galmok

Active member
I just wanted to comment on the new forum software.

While it looks good, it is much too slow. Each page load takes 2 seconds and this makes me reconsider visiting the site. I get annoyed waiting 2 seconds for each and every page load.
 
Unfortunately, the more I look into this, the more it seems like this is heavily related to the software itself. We are looking into what can be done. Sorry for the inconvenience :(
 
9 members and 1004 guests.

Is there a way to limit the 'guests'? Maybe make people sign in before they can view?
 
andino said:
9 members and 1004 guests.

Is there a way to limit the 'guests'? Maybe make people sign in before they can view?
Click to expand...

From my understanding, it's not so much the user count. The slowness is how the newer version of vBulletin handles the forums large database of info. Despite being hosted on faster hardware than it ever was before.
 
Ouch!

Sounds like we might need to move away from vBulletin then. And that sounds like a nightmare. Especially when it comes to migration on the old database.
 
andino said:
Ouch!

Sounds like we might need to move away from vBulletin then. And that sounds like a nightmare. Especially when it comes to migration on the old database.
Click to expand...

i don't think that would even be doable, and even if it would take an absurd time to get it done.
 
It also doesn't have a 20+yr old data base to deal with. Optimizing that may speed up the forum, but I'm not an SME on DB's :\

The best I can do is look at options at this point.
 
It's definitely writing to the database that's the issue. Just refreshing this page + marking it as read is taking nearly a second.

I don't know what 'incrementNodeview' is, but that's almost a second too.

​
 
Oh, and the initial request, and response were almost 2 seconds too.

Is there a testbed you can try out some changes on? Also, have you indexed the heaviest hit databases/tables?
 
Last edited:
Trunks0 said:
It also doesn't have a 20+yr old data base to deal with. Optimizing that may speed up the forum, but I'm not an SME on DB's :\

The best I can do is look at options at this point.
Click to expand...

I like a necro thread as much as the next guy.... probably more... no a lot more... but maybe its time to archive some stuff?
 
We did a tremendous amount of optimizing and creating db index keys and caching to make R3D run as well as it did on the ancient servers we hosted on forever. I have not had the bandwidth to get together with the team who made this absolutely necessary migration happen to talk/walk through possible optimizations. Will see what we can do.

While vB5 may be slower than old vB versions, I don't think it is our database size by itself that is the problem. We just need to dial in some of the caching and index keys over time.
 
The site feels faster today. Still not as fast as it was but getting better.

EDIT: And then I hit post and watched it sit here for 30 seconds thinking....
 
andino said:
Feels a lot better today! Snappy even.
Click to expand...

It does kinda feel like im back to browsing on a 56k. But man this update really killed the already low posting count. Honestly is there no way to just roll back to the old forum even if we lose a few months worth of posts?
 
I remember browsing this site on 56K (which is a crazy thing to say). This is nowhere near as bad. We're simply waiting on database reads/writes, but the page loads are almost instant.
 
This problem will always persist with the upgrade. The only way to avoid the slowness is to not come here anymore. Which, sadly, many have done.
 
Do remember that if you add too many indexes to spead up reads, writes can get very slow. I had a table with a supporting index and removing that index caused writes do from 2-3 seconds to near instant. Clustering correctly also means a lot. And do defragment the database (very important on rotating disks). Try to get a look at which indexes can be removed (if possible). The database could maintain information enough to give clues about this. Some databases also can suggest indexes to make.

Could also be a locking issue (table locks where row locks are enough).

At any rate, getting a clear overview over where the time is used is the first task. Hitting randomly and hoping will take too long.
 
You must log in or register to reply here.
Back
Top