No announcement yet.

Large VBs?

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    I looked at just about every message board product available. Unfortunatly nothing did what we were currently doing with the older v5.x UBB version and I knew it was in need of being updated for many reasons.

    I asked around for assistance in finding a developer who could duplicate the current offerings while also adding additional features as they came up. There was only 1 single person out of all the products out there that made the offer who happened to be from VB. When I asked around the UBB area I got quite a few offers.

    Knowing how heavily customized Hostboard is, user familiarity with its use and my knowledge of being able to administer it I decided to continue to use the UBB software based on the level of help that was offered. That being the re-write was actualy a good idea in the long run as every routine was then able to be custome written and geared towards our appliation and not for the masses.

    I like VB and it community as even though I am a UBB system I have never been turned away or chastised. But rather always given comments, ideas & suggestions
    Running custom version of vBulletin based on v4.2.5
    PHP 7.4.14 :: MariaDB 10.5.8


    • #17
      That makes sense, although i recon we will convert you one day I am not sure why adding a 2nd server for mySQL would be hard for you. Where are you connecting to mySQL? all it should involve is changing the location of the server where you are connecting.
      Christopher Padfield
      Web Based Helpdesk
      DeskPRO v3.0.3 Released - Download Demo Now!


      • #18
        Originally posted by 1QuickSI

        Throwing hardware at a solution is only a partial solution as one needs to look at the entire systems configuration as well.

        I already run on a rather large dedicated server and do not think a bigger one would help. Server loads are very low but at the current growth I want to start thinking of what the next step would/should be.

        Compaq DL380 w/twin 1ghz cpu's and 2gig RAM OS runs on first disk array comprised of 4 9.1gig SCSI3 10k rpm drives arranged in a RAID5 configuration with an online hot spare and redundent power supply.

        Then a Compaq 5302 controller with 64mb cache connects to a Compaq U2 sub-chasis with 7 (has a capacity for 12) 18.2gig SCSI3 10k rpm again RAID5 with an online hot spare and redundent power supply. This is where UBB sits.

        This all links via a gigabyte nic to a Nexland ISB Pro800 router on a SDSL line.

        All connected to a APC 1400rm2u UPS.

        Running RedHat 7.2 Profesional.

        Look at the likes of large systems like EZBoard who must run on some sort of serve farm. I can't imagine splitting database quries to another server can be all that difficult. Or maybe it is just MySQL that is not at this level and one should look at PostgreSQL or another database solution?

        Run a distributive hardware architecture? Are you sure? Are there any examples you can give as I would like to talk to them and get an idea of their board size, hardware, etc.
        This board runs like that. If the board was on it's own it would not need to but various other boards are run on the same server so the various boards have one server for Apache/php and one for MySQL. As Chris said it is literally a 30 second procedure, not including the time to transfer your database to the other server.


        • #19
          We're currently running at around MAX 700 concurrent users, with about 1.2million posts. And we are still on a single server. We are in the process of upgrading, but I do have an important question I'd like someone else with a very large VB board. Has anyone found a way to split the 'posts' database table and the search 'search/searchindex/words' database tables, so that archiving and searching of old posts could be done? Is this possible? This would solve almost all of our speed and CPU issues.




          • #20
            This would solve almost all of our speed and CPU issues.
            I like your logic - rather than having a dedicated db server you want so split up the database


            • #21
              Ha-ha - The problem lies between the keyboard and the chair - he-he

              Originally posted by BillaBongUSA
              [Edit: Dang, Cary beat me because my computer was being dumb!]


              • #22
                The logic is simple, the database has grown over the past 4 years, vBulletin relies on selecting and reading through a mySQL database that relies on speed based on size of tables. To understand if it would be worth it to archive or split tables, you'd need to understand the mySQL habits of vBulletin.

                90% of the work MySQL (and CPUs) does comes through the posts table and the search tables. As these grow, so the speed of the board goes down. (It only matters when you have at least 1,000,000+ posts in there)

                The concept (and I know its hard to grasp) is to split or archive the last 3 1/2 years of data, while allowing the users to still search and browse through all of the data. (provided we make a few changes to the searching and browsing capabilities)

                One solution would be to archive a large portion of the tables and still allow searching and browsing through the archived forums. (They would reside in a seperate series of tables) default searching and browsing would be limited to what is currently in the last 6 months (orginal tables) but if a checkbox is checked ('search all archives') this would allow the users to search all the archives as well as the last 6 months. It would need to be seamless to the user. (This is a concept that includes ideas to the implementation, and from what I've read, I'm going to have to design a hack for this myself.) The system could even archive in incremental tables (6 month archives, 1 year archives all exact duplicates of the originals, not hacks) The art of this little idea, would be the rewrite of the searching and forum browsing code.

                With this ability the board would always be at the optimum speed, since reading and replying to posts would not take so long, and searching could even be implemented to a premium service if you wanted to go back over the last so many years of data.

                I might as well explain the entire concept, since some of you were having a little trouble with it.



                • #23
                  Your board isn't huge - even we have more posts are we are small fry in the scheme of things. We run our forums on a single server and rarely have a load average above 1.0

                  If you had 10m+ posts then there might be some value in doing what you propose however before you get even close to that stage then a dedicated mysql server is the way to go.


                  • #24
                    Thanks Dave. It's nice to have a response without the "What the heck are you talking about?" reply. (I guess some of the other posts were deleted)

                    We're moving our servers from the U.S. to the UK, so we'll be looking into that.

                    Thanks again.



                    • #25
                      This is a big site (not mine)

                      And registration has been closed for many months nows.


                      • #26
                        Originally posted by Drile
                        This is a big site (not mine)

                        And registration has been closed for many months nows.
                        wrong thread


                        • #27
                          Originally posted by Dave#
                          wrong thread
                          I thought the person wanted an example of a "big board."

                          My bad, sorry.


                          widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.