Simple and fast. It runs slow enough now. Can't you turn off certain features?

Fast is all that matters. Ive been to sites with slow BBs and man are they nerve-racking.

why don't you hire an IT guy to take care of the systems while you focus more on your "real" business, which is selling parts.
I also sell on-line and I can't imagine spending my whole day trying to work out system bugs. that's why I outsource all these things, shopping cart, server, maintenance, etc.. this leaves me time to focus on the "bread and butter" of my business, which is buying and selling books, I need to be present at auctions to get that great deal to pass savings onto customer. I can't be bogged down with server issues.

"why don't you hire an IT guy to take care of the systems while you focus more on your "real" business, which is selling parts."

As flush as Wayne is;) servers are expensive. I'm sure a small to moderate business man like himself wants to cut overhead wherever he can.

Another forum that I frequent every day has been running version 3.6.4 of vBulletin since January.

Version 3 seems very solid.

Can you not run a test board using a copy of this database through the later software and see how it goes? I would be up for a bit of testing if you can get a backline/test board organised.

I'm not exactly au fait with vBulletin (am using Invision), but think if the latest version has been out there for a while, and is working on boards with similar traffic levels, then then go to it.

PS: keep up the good work!

Will the new system prevent dropping me and forcing me to log in every 2 weeks or so?

This is why test boards are a good idea; to see whether the latest version does what it says on the tin or not.

The latest version of the software I use is way ahead of the versions we were running even two or three months ago, the architects have really simplified a lot of the SQL side. Testing the latest vB stuff would be the first thing I would do.

Just out of curiosity, what FullText limitations are causing you problems?

If you had a Mac, you wouldn't have these problems. (*ducks*)

Seriously though, the sales portion of the site seems to be pretty stable and quick - this is isolated to the BBS-es it seems.

Hopefully you can come up with what ever fixes the problem of the board just hanging up sometimes when you click on a thread. Sometimes things come up lightning fast, other times it seems like I have a dial up modem.

Pelican has been very slow sometimes at work and home for the last couple weeks.

where is the slow down, IO wait (what raid are you using ?? Hardware raid or software), are you swapping in stead of in RAM?

Are the cpu's pegged with system or user time???

SQLSvr2k5 (or whatever) would introduce a whole raft of other problems. All DMBSs have their quirks.

That said, we use Oracle for our real-time, high-volume stuff. I'm talking multiple terabytes. Probably into the petabytes in some cases.

Yep... I hear ya. I'm currently contracted as the DB architect of the Oracle cluster that's feeding EA's new SportsWorld (http://www.easportsworld.com), the real-time on-line integration for all EA Sports games (Madden, Fifa, etc) on XBox, PS3, etc.

In my heavily-biased opinion, Oracle is THE DB of choice when it comes to needing performance.

That being said, I can't see PP forking over the licensing costs for Oracle any time soon...

I think the trick is to figure out where the performance bottleneck actually is, as was alluded to before (memory, disk io, or cpu contention), and then see if you can't re-architect some of the hardware to eliminate that bottleneck.

If you can keep all searches in memory, that's IDEAL. As soon as you hit physical disk, you suffer at least a 1000% performance hit.

If you're running into CPU issues (all cores are maxed out), then you need to add more CPU cores.

If you're drives aren't responding fast enough, then you may have to upgrade your existing drives or add more spindles. It's ALL about RPM's and number of spindles. If you have 10k RPM drives, simply replacing them with 15k will give you a 40% response time increase.

Otherwise, add more drives, and ensure that you're running the proper RAID for your requirements. RAID 5 is a compromise. RAID 10 is ideal, but is your most expensive.

Also, ensure that you have multiple IO paths to your drives... check to see if you're maxing out your drive throughput.

If you're running out of memory, then you need to add more, unless you're already max'd out.

But of course, it's sometimes not possible to keep everything in RAM (at least on one box).

I've seen other sites set things up in this kind of scenario (large amount of searchable data, MySQL, etc) so that the main tables are on physical drives on the local box (hardware/software RAID-whatever works), but the search indexes are spread out onto other machines via iSCSI mount points (using netfiler, etc), from other boxes, on a switched 1-10GB network. Those other boxes are nothing more than diskless servers with a net boot, and monster amounts of RAM. The netfiler iSCSI mounts are actually 32GB RAM disks.

6 plain jane boxes with nothing but RAM in them, cheaper than licensing other products, etc.

It's like a poor-man's implementation of a solid state drive set up.

The only caveat is that if you reboot the RAMDISK boxes, you have to rebuild the search indexes. Typically, though, that doesn't take that long to do, even on large sites. (Usually under 10 minutes, depending on size). If you have to do that once every 6 months, that's a reasonable trade-off.


Of course, it all depends on the details... how many rows in base tables, what columns in what tables are indexed for search, how large those text search indexes are, etc., etc.

I haven't really seen any specific numbers on that stuff though so I can't comment on it.


$0.02


...jeff

I saw that link, read through it, and didn't see any "limitations" mentioned, other than poor performance.

the board is fast today

Sometimes it doesn't matter how much Hardware is thrown at a problem, if the software isn't working right.

Yes. It has been. Very, very slow.

Wayne, it flip-flops between fast and excruciatingly slow / dead. For the past few weeks it's been spending a lot of time in the latter state.