»
Tech Talk
»
Geek Stuff
»
vBulletin vs Ultimate Bulletin
| Geek Stuff |
|
vBulletin vs Ultimate Bulletin |
|
|
Parker Member Elite
since 2000-01-06
Posts 3129ON |
Ron, Just wondering if you did a compare of vBulletin to Ultimate Bulletin software and whether you think vBulletin is as good. Parker |
||
| © Copyright 2001 James Haley - All Rights Reserved | |||
|
Ron
Administrator
Member Rara Avis
since 1999-05-19
Posts 8669Michigan, US |
Yea, I did, Parker, though I haven't looked at vBulletin in probably close to a year. There are essentially two major differences between the two. vBulletin is written in PHP, a different language than the UBB's Perl. Not only is the syntax different, but the whole paradigm is different. In Perl, I write a program and, because I'm outputting web pages, I'll have a fair amount of HTML code in my Perl code. In PHP, I instead create a web page and embed my program code within the HTML. That's not necessarily bad, just different. PHP, when properly implemented on the server, is both faster and most efficient that Perl (but mod_perl and Fast-CGI are two ways to accomplish the same thing with Perl). An even bigger difference between vBulletin and UBB is the way they handle the data files. UBB is designed to run on any server, with no other requirements, so all of the data in the forum is written to disk as pure text files. vBulletin, on the other hand, was initially written to use mySQL, a compiled (read that as FAST) relational database that is both free and readily available across the Internet. The advantage to an SQL backend is speed and, just as importantly, flexibility. It is often a major pain to add functionality to the UBB, because all disk routines have to be written from scratch. With a relational database sitting behind the data, though, it can be as easy as writing a new SQL command to extract the data in a whole different way. Unfortunately, as of a year ago, vBulletin's greatest strength was also it's most serious weakness. Each of our forum threads are stored as a single text file on the server's disk. If you and I are both writing to the same thread and hit the Submit button at exactly the same second, there's going to be a delay for one of us. That's because both of us can't write to the file simultaneously. The first person to get there "locks" the file, and the second one has to wait until that lock is released. That's a problem inherent in any multi-user system. How much of a problem it becomes in reality is largely a matter of "granularity." In our text based system, we have a very high level of granularity. Each thread is its own granule, and what I do in thread A doesn't impact people working on thread B. In a relational design, however, it's almost impossible to get that same degree of granularity. Most RDBM systems store all the data in a single disk file, and locks are put not on a single thread (record), but on a group represented by a disk block. In MS Access, for example, writing to a record results in a 4K lock of everything around that record. That typically means that about 8 records on either side of the one being accessed also become locked. If two people are writing to records within a 4K block, the system has no option except to make one of them wait. Multiply that wait by a few hundred, or a few thousand, users and the speed we gained from a Relational database goes down the drain. Sadly, for vBulletin, the story gets worse. Every relational database has a different level of granularity, and the 4K one for Access is just one example. The mySQL database that vBulletin has used since its inception was designed primarily for speed and ease of use, not for really data-intensive operations. As of a year ago, mySQL had no granularity at all. If a user was writing to the database, the whole database was locked until the write was completed. Ouch. The design decisions made for vBulletin make it a very fast and efficient engine for forums without a lot of traffic. And that, actually, accounts for probably 95 percent of the forums out there. Most have no more than a few users logged in at one time, and those few rarely hit the Submit button simultaneously, so vBulletin runs like greased lightening. But larger forums, like ours, quickly discover their system is spending a LOT of time waiting for locks to be released and everything starts to feel like molasses rolling up hill in mid-January. When I last looked at vBulletin, close to a year ago, there were plans to port it to other relational databases, ones with a bit more granularity. Don't know if that's happened yet. And mySQL, for at least three years, has been promising to eliminate their granularity problems. Don't know if that's happened yet, either. When it's time to upgrade our software (and we're getting there), I'll probably take another look at the options. But I honestly suspect it would be difficult to move to any other platform, because none of them have many of the things we do and it's always tough to move backwards (even if it's a step forwards). There's actually very little UBB code left in our system, and I suspect our next upgrade will eliminate even that little. I spent quite a bit of time last month working with a relational database called PostgreSQL, but eventually decided it wasn't any more ready for prime time than is mySQL. Unless you get into the ranks of Oracle or SysBase (and we're talking $50,000 entrance fees), the cheapy SQL databases available for the web just aren't stable enough for really heavy-duty use. But I'm still looking…  |
||
|
|
⇧ top of page ⇧ |
|
| All times are ET (US). All dates are in Year-Month-Day format. | ||
