To FQ: Switch from UBB to vBulletin...good idea?

[george_c]

Hi:
I'm considering switching from UBB to VBulletin (vbulletin.com), since the later is supposedly a lot more robust and efficient in general cases. My question is more to Futurequest than anyone else...would VB run more efficiently and consume less resources than UBB from FQ's standpoint? I'm on Taz, and I've heard the mySQL component of VB can put more of a strain on the server than the CGI calls UBB makes. Do you have any account holders that host a popular VB board, and if so, how does it affect server performance?

Thanks,

[Deb]

In this area they both have their own advantages and disadvantages.[nbsp][nbsp]For the host they both are resource hogs affecting different areas but each taking their fair share.

As a host -- We do not like either of them.

As a site owner -- It is best that you choose the one which will work best for your site's requirements and one that you and your visitor's are most comfortable working with.

FutureQuest hosts quite a few popular UBBs and VBulletins.[nbsp][nbsp]Site owners seem happy both ways with the differences being only with their own preferences.

Deb
[nbsp]- In the end the choice is yours.

[Shalazar]

Or you can go with WWWThreads, which is much cooler anyway =)[nbsp][nbsp]And will soon come in a PHP flavor too.

[Charles Capps]

Before switching, I'd wait for UBB6...[nbsp][nbsp]Moving to vB might be a hasty decision.[nbsp][nbsp]:)

[george_c]

Thanks guys...I was under the impression that VB was significantly more efficient than UBB. I will wait until UBB 6 comes out, as good old Charles suggests, before revisiting this issue :)

[Deb]

Or you can go with WWWThreads Now that's something we are considering doing for aota.net.[nbsp][nbsp]I'm just not sure how hard it is going to be to import the current data into WWWThreads yet...

Deb
[nbsp]- Removing ourselves from the cat fight.

[Dan Kaplan]

Anecdotal evidence at best, but Gossamer Threads "recently" moved a rather large UBB forum to WWWThreads, and my impression was that the message importing was not a major issue.[nbsp][nbsp]Most of the time involvement seemed to be getting the new forum set up as desired.

Dan
[This message has been edited by Dan Kaplan (edited 10-24-00@5:55 pm)]

[Charles Capps]

vB slows down just like UBB, only it takes about four times as much traffic to do so...[nbsp][nbsp]Why in the world they decided to stick all the posts in just *ONE* table is beyond my understanding.[nbsp][nbsp]Not to mention they keep all the configuration data in tables... Every pageview needs at least three querys, BEFORE it gets to the content....

[badboy]

Charles Capps,

I know you are good with scripting and such, but since you are making money from Infopop, I don't know how valid your points actually are!

Before switching, I'd wait for UBB6...[nbsp][nbsp]Moving to vB might be a hasty decision.
I would suggest that you wait for the upcoming release of Vbulletin (which will be out soon), because it is going to put UBB6, and opentopic to shame in many ways. I believe it is going to be highly optimized compared to it's current state as well.

The UBB will still be flat text files, which means it will not be able to match vbulletin, or wwwthreads for that matter!

Sorry, but I used to use the UBB for a long time (with a forum that has over 100,000 posts. I have since switched to vbulletin, and have never looked back. It is so superior to the UBB, and the flat text file format that I just could not ever go back to Infopop.

So from an *unbiassed* person, I would highly recommend you watch out for the future release of vbulletin, rather than wait for another flat text file version of the UBB!

[Chris Schreiber]

Just thought I would throw in my $.02 worth here....

Both UBB and vB are going to need and use alot of resources above what serving a static web page would, that's the nature of an interactive forum.[nbsp][nbsp]However, I have found that vB, when all the components are properly tuned, to be faster then UBB overall when running with similar loads in the same configuration.[nbsp][nbsp]I've also seen posts from users at sites that have made to conversion saying that vB seemed to perform better as well.[nbsp][nbsp]All of this with the added features you get in vB that aren't a part of the UBB.

Now, vB is still a relative young package (just released back in April), so there are still some inefficient queries that need to be re-written and there are some other places where multiple queries can be combined into joins.[nbsp][nbsp]Many of these issues have been addressed and are being worked on for the next major vB release due within about a month from now.

The key advantage that vB will always have over UBB is storing everything inside the database, instead of using flat files.[nbsp][nbsp]I know one very large site that had to purge posts each week to keep their UBB forums running, imported all of the information into vB after conversion and now have over 1 million posts, all without a problem.[nbsp][nbsp]When searching for a record, if you have a key value, you can get it immediately from a database... if you need to find that same information from a flat file, good luck.[nbsp][nbsp]A good example would be to try searching for a post in a UBB forum, then try the same thing in vB.... I am sure you all already know which is faster.

(Disclaimer: I am a moderator at vbulletin, but I am not a Jelsoft employee)

-Chris

[PaulKroll]

Why in the world they decided to stick all the posts in just *ONE* table is beyond my understanding.
Isn't that perfectly reasonable normalization? You have a table for forums. A table for headlines. A table for posts. You have fields for headlines to associate with forums, you have fields for posts to associate with headlines.

I've not looked at the vBulletin code so forgive the surface assumption, but just offhand a single table for posts doesn't seem like a failing. I'd doubt it's the only one doing this. :)

The other issue, 3 queries for a single pageview, well that sounds brutal, especially considering the session tracking would almost certainly be ANOTHER query. From the talk about vBulletin's draw on resources I'm betting there's, oh, NO caching. As Terra pointed out (in this thread or a similar one) many of these critters were "designed" on a single-user server where they perform "Just Fine!" no matter how they drink resources.
[This message has been edited by PaulKroll (edited 10-24-00@5:34 pm)]

[Chris Schreiber]

Isn't that perfectly reasonable normalization?
Yes according to E. F. Codd it is :)

In a database, the number of records that are in a single table doesn't matter, as long as they are properly indexed you can find the record(s) you need very quickly.[nbsp][nbsp]I am currently working with a database that has over 1000 users and some tables have hunderds of millions of records, it doesn't make a difference.

The point about multiple queries for each page view is a valid concern.... there have already been some hacks developed that reduce the number of queries, and this is a major goal of the next release to cut down on queries even more so.

-Chris

[PaulKroll]

When searching for a record, if you have a key value, you can get it immediately from a database... if you need to find that same information from a flat file, good luck.
OK, I'll bite: if you have a set of highly optimized queries to pull out data from a database and stuff it into a template with minimal code, that's pretty quick.

However...

If you have a URL to a static page, there's nothing faster. Period. It's obvious: in the least case, a PHP or Perl script is a file loaded, parsed, data sent. In a static page, the file is loaded and sent. There's no parsing. There's certainly no database querying. It's just like, done. :)

Generating a static page or protecting it in the case of "members-only" forums, that takes work, either in flat files or databases. Searching, that takes work, and that's pretty clearly a place where a database makes a whole heckuva lotta sense. (Assuming, of course, that you're using a database of keywords: not much point doing "like '%word%'" or you might as well be back to flat files.)

From what I've seen none of the vBulletin pages are static, but all the dynamic work that IS done is done pretty quickly (no CGI/process overhead by using PHP, more effcient searches). Some of the UBB pages are static, but key areas are not: searching and the oft-hit "recently updated" or "home pages" for each forum.

This whole area is incredibly frustrating for those of us who want fast, flexible, user-friendly discussion group systems: How Fast Are They Really? How well do they scale? I've brought up before the question of "does anyone have like, any benchmarks, anything even close to relevant?"[nbsp][nbsp]It can't be impossible to make that sort of thing up: it's only brutally tedious. :)

[george_c]

Wow, a lot of useful discussions going on here! I will definitely watch out for the next release of VB, since it now seems the next major release of UBB and VB will be at around the same time.

One question to people familar with VBulletin here...how is support? I've been lurking in the VB Community Forums lately, and one thing that got me worried was the # of posts complaining about lack of support.
------------------
Visit http://wsabstract.com for JavaScript tutorials and free scripts.

[Charles Capps]

Let me quote TeRRa: Everyone is amazed by VBulletin, but to burst the bubble - it is extremely heavy on resources with large amounts of CPU/Memory/MySQL interactions necessary to complete the task...[nbsp][nbsp]If they keep going the direction they are, it will quickly surpass the UBB in resources required...[nbsp][nbsp]If you watched this monster slurp up resources (in production), it would make your jaw drop and sullenly shaking your head realizing that a server can only handle a small handful of these running at any one time...[nbsp][nbsp]We've been lucky so far with minimal clashes, but there will be a day when everyone will want to run one...[nbsp][nbsp]The UBB did that, and was banned from many hosts - VBulletin will be next (I guarantee it)...[nbsp][nbsp]You might want to read the thread (http://www.aota.net/ubb/Forum5/HTML/000937-2.html) that I pulled the quote out of for additional context.

I've experienced this first hand.[nbsp][nbsp]I recently was hired to do a little project with a vB... I was completely shocked at how it was put together.[nbsp][nbsp]The scripts I tried to design nearly fell apart because I couldn't figure out how to handle all the data that had to be extracted from the SQL table effeciently.[nbsp][nbsp]How vB (or if vB) does that, I have no idea.

Both UBB and vB have a long way to go.[nbsp][nbsp]

If you're using UBB now, stick with it and wait until UBB6.[nbsp][nbsp]If you're using vB, stick with it and wait for that next release.[nbsp][nbsp]There's really no reason to switch.[nbsp][nbsp]The performance gain you may get by switching from UBB5 to vB might not be worth it in the long run...[nbsp][nbsp]

[Terra]

If they keep going the direction they are, To ensure my quote remains in context, the key sentence fragment is displayed above...

Change will be good!

I do not feel that any message forum will ever be perfect, resource wise, as it is just the nature of the beast...

I spent a great deal of time tuning the servers for the demands of the UBB, which is by far the most popular heavy script...[nbsp][nbsp]Now with the proliferation of vBulletin, I must now start to remold the performance characteristics and walk a fine line between the two...

In the end, you have a resource war between the two and I can honestly say that I favor none above all...

Use what works best for you and your visitors...

--
Terra
--There really is no right answer to the contention--
FutureQuest

[Chris Schreiber]

If you have a URL to a static page, there's nothing faster. Period.
I won't disagree here, viewing a static page will always be faster then viewing a dynamically created one.[nbsp][nbsp]There has been talk before about making static pages an option in vB, I am not sure if this will ever happen, but if it was an option to have static pages, I wouldn't use it.

Why?[nbsp][nbsp]Some of vB's neatest features are because of the dynamic pages... like the "blue arrow" links that automatically scroll you down to the first un-read post... I can't begin to tell you what a time-saver this can be not having to re-read a post, just to figure out you've already read it the last time.[nbsp][nbsp]Also, all of the user information and signatures are automatically up-to-date.[nbsp][nbsp]If I change my sig, it is reflected in all the posts... no more "Updating threads" which can take forever on some systems.

-Chris

[Chris Schreiber]

Let me quote TeRRa:
Funny, I've seen that quote before.[nbsp][nbsp]

That's actually an interesting marketing technique called FUD: Fear, Uncertainty, Doubt.[nbsp][nbsp]"If they keep going the direction they are, it will quickly surpass the UBB in resources required...[nbsp][nbsp]VBulletin will be next (I guarantee it)...".[nbsp][nbsp]There are alot of "ifs" in that statement there... Many resource problems have already been identified and most are in the process of being corrected.[nbsp][nbsp]vB was never meant to be "commercial" software, John basically wrote it for his web site without any plans on releasing it.[nbsp][nbsp]This is the main reason why it's never been stress-tested for performance, because the server he ran it on was always more then enough.[nbsp][nbsp]vB will only get faster from here, not slower.

Both UBB and vB have a long way to go.
Wow we agree on something :)[nbsp][nbsp]Like I've said, vB is a young product, and still needs some more time to mature.[nbsp][nbsp]I give InfoPop alot of credit for being the first to market with a great forum software.[nbsp][nbsp]But I've really lost respect for their stance on many things (I am not going to go into them here, but anyone that visits scriptkeeper will probably know what I am referring to).[nbsp][nbsp]I have a strong belief that in order for forum software to handle more users, more posts and still add more features, it *must* be database-driven.

-Chris

[badboy]

The UBB has badly bloated code, that has never even been optimized, only added to time and time again. It really has been completely pieced together over the years. There is no room for argument here, because I have worked with it first hand, and it is bad!

Take a look at the vbulletin code! It is quite clean and coded well. I know it needs some SQL optizization, but the core code seems to be coded well.

Take a look at features. The vbulletin board has administrative options that blow the UBB out of the water. Also it matches and beats every aspect of the UBB as far as features are concerned.

Really want to test speed. Try going to each support forum, because I think you will find that it takes ages to get through the scriptkeeper forums in comparison with the vbulletin support forum.

I know that UBB is redoing code for their next version, but they are not adding many features, only fixing the bloated excessive code problems the UBB has. So in my mind the vbulletin is still better to work with because it has features that you will never see the UBB, only OpenTopic (which is a complete waste of money because of their terrible hosting issues!).