I work for vBulletin and have some input on this. First off, you really should look into upgrading to version 2.2.x, as not only are there many new features, but there have been a number of performance enhancements done that may help your situation. You also might want to take a look at the vBulletin forums ( http://www.vbulletin.com/forums/ ) for MySQL & Server Configuration, where we might be able to give some more tuning help specific to vBulletin.
I know a few sites that are using InnoDB, or have tested using InnoDB tables. vBulletin will run just fine in this configuration, however there is one issue many users have run into: InnoDB does not store table counts, so select count(*) from table-name statements can take a while, and there three of these statements on the main index.php page for the total number of users, threads and posts. There are some workarounds you could look into, read this thread for more information on that: http://www.vbulletin.com/forum/showthread.php?s=&threadid=36219 >From the InnoDB manual: InnoDB does not keep internally a count of rows in a table, which would actually be somewhat complicated because of multiversioning. To answer a query SELECT COUNT(*) FROM T InnoDB has to scan one index of the table, which will take some time if the table is not entirely in the buffer pool. To get a fast count you have to use a counter table you create yourself, and let your application update it according to the inserts and deletes it does. A way to eliminate the bottleneck posed by lock waits for the counter is to create a whole set of counters. The application can choose one at random each time. To get the count, just sum the counters: SELECT SUM(counter_column) FROM your_counter_table. Hope this helps, Chris Schreiber -----Original Message----- From: Byron Albert [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 3:03 AM To: [EMAIL PROTECTED] Subject: innodb and vbulletin 1.1 Hello, I have a few questions. First I work on a very high traffic site that uses vbulletin 1.1 to run its bb. The bb is very high traffic around 60-200 concurrent users. We are starting to run into some serious locking issues, and I am thinking about converting the high use tables(maby all) to innodb. My first question is will this break anything in the application layer? Second we may be moving this to a new serve where I could have 6+ disks. I have done some testing and found that after all the importing into innodb all the data is around 1gb. Would it be helpful to add these extra disks creating 1+gb raw partition on each one to spread the io across the disks and controllers. And how does innodb distribute the data through the table spaces? Thanks for any help Byron [EMAIL PROTECTED] --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
