Announcement

Collapse
No announcement yet.

Large VBs?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    My bad, sorry.

    Leave a comment:


  • Dave#
    replied
    Originally posted by Drile
    This is a big site (not mine) http://www.anyoneseenthebridge.com/msgboard

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

    Leave a comment:


  • Drile
    replied
    This is a big site (not mine) http://www.anyoneseenthebridge.com/msgboard

    And registration has been closed for many months nows.

    Leave a comment:


  • marcusware
    replied
    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.

    Marcus

    Leave a comment:


  • Dave#
    replied
    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.

    Leave a comment:


  • marcusware
    replied
    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.

    Marcus

    Leave a comment:


  • Marula
    replied
    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!]

    Leave a comment:


  • Dave#
    replied
    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

    Leave a comment:


  • marcusware
    replied
    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.

    Thanks.

    Marcus

    Leave a comment:


  • JamesUS
    replied
    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.

    Leave a comment:


  • chrispadfield
    replied
    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.

    Leave a comment:


  • 1QuickSI
    replied
    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

    Leave a comment:


  • chrispadfield
    replied
    It honestly does seem like you have gone through a lot of work, what i don't really understand is why not just use vb instead? i realise you have a few custom things like creating forums etc.. but abstracting the code form the admin area to do that would take about half an hour - less time i would imagine than rewriting UBB (shudders).

    Leave a comment:


  • 1QuickSI
    replied
    No there are no problems with the site or server loading at this time. I am just trying to speculate in to the future what might be neccessary. As for users online, normaly there are around 100 at any given time. Given the holiday usage was expected to go down.

    I agree with RAID 5 but the the amount of data being written at any one time is really minimal and the caching controller really has helped in this area.

    We have done some MySQL optimization as you can imagine converting a UBB was not small task. Each piece of code that needed to be re-written is customized to this particular appliaction and not for a mass market product. Our DB developer thinks he might be able to do some more tweaking but there is not much performance left to get out of it.

    I am jelous that moving to a second server is as easy as you state. I am sure we will have much more work. But it has been well worth it as MySQL has had a dramatic improvement in the systems performace.

    And one more thing...

    Thank you to the people that have taken the time to respond. ti has given me some insight and I know now that I do have a bit of a ways to go before I reach any of this. I know we run 2 differnt platforms but bottom line is we do the same thing ultimatly

    Leave a comment:


  • MattR
    replied
    RAID 5 is (usually) not a good solution for an application which gets many writes, since as you know there is more I/O involved in a single write in RAID5 than say RAID 10.

    Leave a comment:

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