I just don’t see much room for the problem wtih be with vBulletin. Not only are there vBulletin-based boards of comparable or larger size w/o our performance issues, there were vBulletin-based boards fitting that description long enough ago that they would have been running version of vBulletin no newer than what we are running now. We don’t even make the first page, and I doubt all those others came from behind and overtook us since the era when our version of vBulletin was the newest and greatest.
vBulletin is just a web-based front end for speaking to a fairly standard SQL back end, isn’t it?
What do you suppose Jerry & co think is the cause of our performance problems?
Threads have been offloaded from the db a few times (to my annoyance & dismay), which at first glace would seem to imply that someone thinks the db was having problems either with overall file size or with sheer record count, but I think that is an erroneous assumption on our part, or else on theirs (more likely ours, I think).
I actually am a database geek. Not MySQL or postgreSQL or MS SQL or Oracle or any of the other big iron systems, just FileMaker. That’s enough to give me some thoughts & concerns though —
You could not run this board on FileMaker because it would be too slow and would not accomodate enough concurrent users. But you could sure as hell read the board in single-user mode with no problem’s due to db size. 10-20 gigs is not particularly huge for FileMaker. I would think that would certainly be true of the various SQL systems? Some SQL dbs are chock full of blobs (binary large objects, including movies and sounds and pictures and document files and whatnot). I’m pretty sure they get massively huge.
Nor should 8-million-someodd records be a problem. In FileMaker there’s a ludicrously huge maximum number of records. It gets unweildy at doing searches long before you get anywhere close to that, because FileMaker is slow. So again, I have a hard time believing a SQL type db system would be choking due to the number of records that our board is comprised of.
So, yeah, I’m very curious about WHAT, exactly, is the bottleneck?
My WORRY is that it has something to do with a corruption. THAT I could believe would slow searching to a crawl; would cause a db administrator to think offloading a batch of the oldest records was worth a try (if it’s a long-term problem they’ve known about for years but can’t root out & fix, perhaps it is in the oldest records, somewhere).
I don’t know a lot about SQL db’s and what within them is subject to corruption. Generically speaking, databases consist of the raw data + the structure. Could the structure be corrupted? The table structure of the board doesn’t look awesomely complicated. Users, Forums, Threads, Posts. Perhaps a Status table attached to Users. Perhaps a few other ancillary tables. Seems like if the structure were corrupted, it wouldn’t be horrendously awful to rebuilt it and then import the data.
How about the data itself? Is is possible, and likely, that the data in the Posts table or the Threads table somehow contains batches of mangled stuff that impinges on the performance of the system? And that it’s hard to isolate and weed out? As I said, I could see a db admin exporting and then deleting a batch of old records if this is what they were thinking, and were hoping the corruption was in those older records.