No announcement yet.

Thinking of switching my UBB to the vB 2

  • Filter
  • Time
  • Show
Clear All
new posts

  • Thinking of switching my UBB to the vB 2

    I have a large UBB version 5.47 that I am contemplating switching to the vB 2. I have read the vB is faster and such. Will the vB handle large traffic better then the UBB. I have nearly 7,000 registered users and I have periods of extreme high activity on my site. It will be conceiveable that I will have 2,000 users online at once. We have had months where we topped 20 million hits on our server almost all on the message boards. Will the vB be able to handle all this traffic. I read on another forum that the vB works great accept when you get up to 25-50 concurrent users. They said then problems will occur. I do have a dedicated server. Will high traffic periods be a problem? What is the heaviest traffic site that is using the vB? Does anybody have any thoughts on this matter?

  • #2
    Well the vB 2 will save you tons of space, and yeah with 7000 members I'm surprised you don't have a dedicated server. I would switch to vB more defiantly!
    MSN: [email protected] | MAIL: [email protected] | FOLIO:


    • #3
      It depends upon serveral factors, like hardware being used, site traffic, OS on the server, etc. There is one forum that has been outspoken about the failure of VB to handle their high traffic site at If you read some of the posts on their site, they have run into some serious road blocks with VB code and have had trouble with it crashing. Not only that, but they report some users that are on Macs and Web TV are not seeing correct formatting of the forum and those users can't use the site.

      I have posted this question myself concerning the viewing of my forum for testing with a Mac and Web TV, but no one has replied to the site check (see site check post from me) yet. This is an area I'm somewhat skeptic of until I get a confirmed report from a known user on Macs and Web TV testing my site.

      The site has high traffic and about 18-20K members. About 150-400 users or on at any given time depending upon time of day, etc. Their hardware specs they state are more than up to the task of running VB, but I wonder about certain key areas. I don't know just how much VB can handle before it gets freaky and causes table lock-ups and crashes like they expierenced at their site. A MySQL and PHP backend database can only handle so much and doing heavy read/writes at the same time (which they had happen) can cause database crashing.

      How one could solve this issue is something they couldn't do or figure out. So, they ended up going back to UBB 5.X to handle the load and it does just fine since it's not PHP/MySQL database driven. However, UBB 6.X would be just as bad as VB and even worse perhaps since it caches the pages and such so the load would be just as bad.

      How much VB can take, the hardware specs required and the exact how to for setting that hardware/software up is somehting I don't know about and hasn't been stated here. Maybe we can find out if the developers reply. I know it would sure be interesting to hear how high-traffic sites can be done or if it can be done with VB and what's required for certain to achieve it. Also, finding out how far they've tested the code would be great too.

      Hope things work out for you.



      • #4
        We just hit a record of almost 600 members at one time this week (yay!) and though there are some times the load goes up above 8, it represents maybe 10 minutes collectively.

        I have the php on one server and the mysql on a second server.

        I was a former UBB user and I wouldn't go back to that software for nothing!

        You have to be willing to fine tune your server to work well and not just expect it to be Plug N Play with a board of this size. If you are willing to optimize your server for Vb, you'll have much better success with Vb!
        Last edited by Me2Be; Thu 10th May '01, 3:53pm.


        • #5
          Re: Thinking of switching my UBB to the vB 2

          Originally posted by Boss
          I read on another forum that the vB works great accept when you get up to 25-50 concurrent users.
          That's if you're on virtual/shared hosting. On a dedicated box you'll have no problems hitting much larger numbers than that.

          With 2000 concurrent users, you may have problems because MySQL can scale so far, but after that it will crap out on you. Matt Rogish (of is around these forums; he had to convert to Sybase instead of MySQL for the backend because of MySQL limitations and can probably explain better what the limitations are and why.


          • #6
            How many concurrent users can be on a shared server? What will happen if more than that are online?

            The database can't sure corrupt just because there are too many users, can it?


            • #7
              No, it's not database corruption that you need to worry about, it's getting booted off a shared host. Most shared/virtual hosts limit you to about 30 connections to MySQL at a time.


              • #8
                Boss, one idea to consider is moving to 1.x first, and then see how it goes. Then upgrade to 2.x final when it is ready. If 2.x is too slow, you can go back to 1.x. 1.x is still quite nice but also much faster, since it is less powerful than 2.x. The problems we had at HomeTheaterForum were complex, partially tied to not enough hardware, bugs in the OS (FreeBSD 3.4), and that FreeBSD can't let one process (MySQL) use multiple CPUs at the same time.

                For future large installs I recommend Solaris or Linux with the 2.4 kernel, if you use a multi-cpu setup.



                • #9
                  Moviejeff or anybody,

                  It was said.

                  "I don't know just how much VB can handle before it gets freaky and causes table lock-ups and crashes like they expierenced at their site. "

                  I have seen someone else say something about table problems. Would this have to do with the vB itself, or the backend stuff (A MySQL and PHP backend database) not holding up?

                  Any ideas?
                  Last edited by Boss; Tue 15th May '01, 12:47pm.


                  • #10
                    Depends on the sort of problem you are referring to, but read/write conflicts can be solved using a row locking database (Sybase), or a row/page locking table type in MySQL (BDB, InnoDB).

                    It appears with fast harder you don't need to bother, even for fairly large sites. One site has 600+ users at peak, with two dual 800 (or so) machines. One for web and one for mysql. It runs smooth and fast under peak traffic. Using two machines for bigger sites is really a major win for lots of reasons, if your budget permits.



                    • #11
                      I am referring to the table problem. Is this a flaw in the vB during high traffic situations or is it a due to slow MySQL, PHP, or server issues?


                      • #12
                        I've been hearing a great deal more about this problem, and I am wondering why things cannot be split across multiple SQL servers...

                        I used to visit the forums at - Cliffe, the Site manager, has done everything possible. There is 40,000 registered members and the forums, ALL BY THEMSELVES, run on one server with dual 800Mhz Pentium Xeons with 2GB of RAM and FreeBSD - and the server maxes out at 620 ppl (slow loads, SQL errors, etc).

                        As for UBB - UBB may be less taxing in terms of large sites, but it uses the hard drive like a monster, since it uses a FFDB.

                        I dunno...


                        • #13
                          I don't know what "the table problem" is.

                          Aunt, perhaps he hasn't tried moving the thread and session tables to BDB or InnoDB. That eliminates table locking, using page and row locking instead. No more read/write delays.



                          • #14
                            Originally posted by roy7
                            Aunt, perhaps he hasn't tried moving the thread and session tables to BDB or InnoDB. That eliminates table locking, using page and row locking instead. No more read/write delays.
                            In addition, he's still using an old (beta 3) version of 2.0. Or last I knew he was. Stallion's been wanting to update it but it becomes a big ordeal when you have a large site....


                            • #15
                              The simple fact of the matter is that any server-side web solution is going to require serious hardware when serious amounts of users and traffic are involved.

                              A fatal mistake that I have seen made all to often is to assume that, because MySQL is free, it will run fine on an old cobbled-together server made with your spare parts. Wrong. MySQL is a full scale database server, and as such, it needs ample amounts of hardware behind it to make it run nicely under a heavy load.

                              It freaks me when I see people posting about how MySQL is having problems supporting a hundred users online on their 700MHz Pentium with 512MB of RAM... I mean, let's face it, that's not a server, it's a toy. Nobody would dream of installing Oracle or Sybase on a machine with those specifications, and MySQL is no different.

                              Of course, MySQL is very nice because it doesn't need a lot of hardware to support a light load, so your P700 with half-a-gig is going to cope with about 50 users online with no problem, but after that you are going to need to ditch your toy computer and get a server.

                              UBB is very similar, in that it runs pretty well with a small number of users online, even on a crappy box, but put it under strain and it will start wondering when it's going to be put onto a decent server. Of course, with a database back end, rather than a flat file system, you can go on adding more hardware to the system to cope with increased load, whereas with a file-based system, you will eventually hit a ceiling.

                              Bottom line: vBulletin is a large, complex system doing large, complex things to a large, complex database server. Don't expect it to handle a large site without investing in the hardware to support it. The same goes for just about anything else you might install on your webserver.