PDA

View Full Version : Thinking about switching from UBB but have some questions first



Sharg
Sat 17th Jun '00, 4:19am
Hi,
I'm currently using UBB. I have over 1000 registered users, and a couple of hundreds messages posted daily.
I will have much more posts soon, because I will make advertising for my site.

I'm about to switch to a new hosting provider, and since I will have to reinstall everything, I'm thinking of switching to Vbulletin.

Here is why:
-It takes much less data than ubb (i heard a 250 mb ubb data would take 50 mb with vbulletin).
-It takes too much month for the UBB team to incorporate the hacks. Damn, I’ve been asking since several months for mass move/ mass archive and preview post features, and they were never implemented. I can see they are already on vbulletin.
-On ubb I must disable the search feature, cause it takes damn too much server resources !!

Now here are my questions:

-Well, will vbulletin not consume too much CPU resources ? Since all the pages are generated on the fly, when its only an html page on ubb, in particular on boards with over 20 000 messages (and on a shared virtual hosting ?)
I really want your thoughts about this.

-I have a hack on my ubb that I can't remove: my users LOVES it, and it increase the number of posts. Its a hack where for a certain number of posts, the users have a certain "level + picture". For example when a user has posted 500 messages, he is automatically promoted to the level "Master" with the picture of a warrior.
Could such hack be implemented in Vbulletin ?

Beside these 2 points, I see no reason why I would stay on UBB...

Oh, and just a last question:
Are the good hacks incorpored to the Vbulletin official version rapidly ? I HATE to implement hacks, and have to do it again when a new official version is released, so its important to me to have an official versions with always new official hacks...

I'm waiting for your answers.

Benj

[Edited by Benj on 06-17-2000 at 04:25 PM]

Freddie Bingham
Sat 17th Jun '00, 4:34am
Benji,
I don't believe the development cycle has been going long enough to say whether 'hacks' are quickly implemented into the final version. The memberlist was incorporated but none of the other hacks have been really finzalized yet so it isn't a fair question at this time.

As for the posts and image - yes you can do that now. You can assign user titles based on the amount of posts and you can use HTML in the user title so you can do like this:

500 Posts:

Master<br><img src=warrior.jpg>

That would display "Master" with the warrior jpg underneath it. You can also give unique titles to users and hence unique images. The avatar hack (user can choose their own image) is currently being worked upon and it should appear in a version in the near future.

[Edited by rangersfan on 06-17-2000 at 04:35 PM]

wandrer
Sat 17th Jun '00, 5:35am
-Well, will vbulletin not consume too much CPU resources ? Since all the pages are generated on the fly, when its only an html page on ubb, in particular on boards with over 20 000 messages (and on a shared virtual hosting ?)
I really want your thoughts about this.

CPU load levels will be lower (everything else staying the same) with vbulletin versus UBB.

Pilot
Sun 18th Jun '00, 4:14am
One reason I am still waiting for the right moment to convert to VB is the fact that it is one-way migration - there's no easy way back to UBB after a period of time without losing data and user definitions or having to code up your own extract program.

It would actually be a good idea to provide a VB to UBB migration tool. Since, if VB is really better - people won't go back, but it would give them the confidence to try VB knowing they can go back to UBB if the worst happens and VB is dropped by the developer, or John falls under a bus.

I agree that UBB hacks are a sign of stagnant vendor development as well as user innovation. I have implemented no UBB hacks except simplying the password generation to an all lower case 5 char alpha password instead of the ridiculous 7 character mixed case password it defaults to.

wandrer
Sun 18th Jun '00, 4:34am
It would actually be a good idea to provide a VB to UBB migration tool. Since, if VB is really better - people won't go back,

If you are unsure, backup UBB directory/files. That way, if vb doesn't work out for you (God forbid), you can just FTP back your UBB files. Alot of the 'features' in vb would have a hard time being converted back to UBB (custom user titles, images, replacement variables, etc)...


but it would give them the confidence to try VB knowing they can go back to UBB if the worst happens and VB is dropped by the developer, or John falls under a bus.

The same should go for Infopop. Infopop should provide an automatic UBB to VB/phorum/w3t 'conversion' program. If UBB is really as good as they say, no one would need Infopop's 'conversion' program, but it would be there just incase. Or, heaven forbid, Infopop drops UBB in favor of OT. That 'conversion' program would then give UBB owners a direct conversion to other forum packages once Infopop drops UBB support/development.

Pilot
Mon 19th Jun '00, 12:32am
You're missing the point. If I go to VB and after a
few weeks I don't like it or it is not reliable enough or it has resource problems - I can't go back without losing data and new members. That means I need to be really sure about making the move, and I am not yet.

Obviously one would lose the VB only features - I am talking about having a way back from a migration and not just to the point in time (data-wise) when you did the migration.

I am reading here about DEDICATED MySQL servers running out
of memory! My God - what hope is there to run VB on a shared
service, as I do with UBB, if it can't manage on a dedicated server?

Can VB users using Internet Presence Providers shared MySQL
servers please tell me that it can be done reliably for a
largish board? UBB may be a RAM hog(?) - but it is very
reliable and my IPP is not complaining about resource use.

I am worried that if I migrate - I am (a) committed - no way back without losing data and (b) could end up with MySQL resource server problems when I have no such probs now.

At the moment UBB is the proven software with many users and VB is the new kid on the block. That's why VB providing a way back to UBB would actually HELP it's case against UBB by
reducing the risk of making a switch from UBB to VB.

Until I stop reading about really unpleasant MySQL problems here, I just can't see myself migrating. Why make life hard
for just a few new features? Yes, VB is the better architecture of course but is it right for my board is the question that I don't have an answer for yet.

I don't have a dedicated server and probably never will have. (How much do these cost by the way?)


[Edited by Pilot on 06-19-2000 at 02:01 PM]

Shaman
Mon 19th Jun '00, 11:16pm
If people are running out of memory with their MySQL servers, something *is* wrong. I have a shared MySQL server with some fairly sizable databases with multiple-way sorts being done in-process, and the load rarely bumps 10% on the box (dual processor 550Mhz PIII with RAID0+1 and 1GB RAM, Solaris x86) during *any* time of day - that includes data mining runs on some of the data that does a 12-way sort no 10K records joined with 5.5M records.

If your MySQL is giving you problems, you need to spend more time on tuning it or something. I spent half an afternoon tuning my MySQL server and it's running so well I can scarcely believe it.

wandrer
Mon 19th Jun '00, 11:30pm
dual processor 550Mhz PIII with RAID0+1 and 1GB RAM, Solaris x86)

That is the key. Most other people who were having problems had only 64-128MB of Ram. Once they bumped it up to 256-512MB everything else is fine. Saying that:



If people are running out of memory with their MySQL servers, something *is* wrong.

with 1GB of memory might mislead other people who do not have the setup that you have. I am sure if you tried your data mining with only 128MB, there would be some very 'real' problems.

wandrer
Mon 19th Jun '00, 11:37pm
what hope is there to run VB on a shared
service, as I do with UBB, if it can't manage on a dedicated server?

I have two very happy customers who have switched from UBB to vBulletin that only need 24MB of Ram (MAX ! and that is with Apache/PHP and mysql). They are on shared servers and are extremely happy with vBulletin. Now, they are not getting 1,000's of posts per day - actually they are happy if they get over 5 posts per day (~250 visitors per day viewing their forum)- so that is not a problem.

But as with any setup, you first have to find out of your hardware can support it. You cant expect a VW Bug to do 4.7 drag race or be able to exceed 170MPH. For that, you would need a specialized vehicle. The same goes for vBulletin. A very small shared server isn't going to be able to handle 100's of new posts per day and 1000's of people per day.

But, the solution is not saying 'vBulletin is at fault'. The solution would be to get a hardware system that is going to support your traffic and software.

Pilot
Tue 20th Jun '00, 3:55am
Having just moved hosts - I don't make to make my life hard.

If VB users can tell me that they moved from UBB on the same hosting platform and had no resource problems then great.

What I am not going to do is look for trouble. ALL things being equal I would switch to VB now. But I am not going
to until

(a) I am sure that VB is as reliable and "bug free" as UBB.

(b) That MySQL is not going to give me grief - I don't need to tune flat files so why should I have to tune SQL?

I use PAIR.COM as my host - I can't control what they do - currently I run UBB with no problems. I can't be sure I can do the same with VB and yet people tell you how LESS resource hungry it is! I am not convinced when 50% of my UBB hits are on HTML files and not CGI generated.

The free version of VB will a lot to accelerate the maturing process - that's for sure. There's nothing like a lot of people using the code to shake it down...!

werehere
Tue 20th Jun '00, 4:21am
(a) The UBB is surely not bug free, they have had until recently some of the largest security bugs I have ever seen from any script out there.

I am never going to tell you that this script is bug free, that would be untrue, but at the same time neither is the UBB or windows/Linux/Mac, or anything for that matter. All I do know is that bugs are currently trying to be found and fixed.


(b) You should not have to do any major tuning to MySQL. Most should already have been done during the install from your host. I would not just say you wont or would never because the UBB does require it though, this is after all a database which could possibly require it, and after all is there to make it run better. Trust me, if flat text files could be tuned then you better believe that the UBB would be in need of it most definetly, but that is one reason why that forum software is not up to par with others anymore, because it uses such formats as flat text files, which is inferior to database driven.

wandrer
Tue 20th Jun '00, 4:26am
I am not convinced when 50% of my UBB hits are on HTML files and not CGI generated.

How much available memory do you have on pair.com for your shared server ? How many visitors do you have per day to your forums ? How many posts do you have on your forum ? How many members do you have on your forum ? How many (average) posts per day ?

How many hits do you get per day ?

All that relates to how well vBulletin would operate on your system/website.

doron
Tue 20th Jun '00, 4:36am
I converted my UBB into a vB on a Communitech Virtual Unix Plan. The board is not that big (18818 [i had to prune for the ubb] posts and 722 users). it runs like a charm. CT is known to kill memhog scripts, my ubb got hit twice during search. I imported 18,000 posts and did not get reaped.

mysql on a shared is no problem, as they have enough memory. What I did was this - get the VB, convert, and letusers test the new forum. If it is slow/whatever, you decide then.

Martin
Tue 20th Jun '00, 5:07am
actually, mySQL is probably better on a shared solution since the hosting companies (the good ones, anyway) have dedicated mySQL server that are set up and tuned to handle large volumes of traffic. It saves you the hassle of trying to tune your own PHP/mySQL, something I'm still in the process of doing.

Sharg
Tue 20th Jun '00, 7:47am
Well yes :)
Just installed Vb today, and my host has 2 dedicated mysql boxes.

I know nothing about php and mysql, yet I was able to install the script in 10 minutes, all working after the first shot !

Benj

Pilot
Tue 20th Jun '00, 6:45pm
Pentium III 667 Mhz, 256MB RAM, 20.5GB disk

is the Pair hardware they use for the shared web
server - plus similar for a separate shared database server.

I have 1500 registered users, and about 10,000 posts
in total. Something like 150 new posts per day. Quite
a lot more browsing only - around 1000 users per day.

About 150 MB of HTTP data per day is sent.

So - what's the verdict - VB feasible or not?

UserName
Tue 20th Jun '00, 7:18pm
I have a dual Pentium 500 w/ 500 megs of ram running Linux. My board has close to 1500 users with over 30,000 posts and I do over 500 meg a day served from the vB scripts on my site. Almost my entire site is served off of that one dedicated server and it is not uncommon for me to do over 40 gig of transfer per day (sometimes quite a bit more than that) site wide from the machine. With all of that, I have, so far, had zero problems with vBulletin. The "load average" from my server (using the Top command) rarely rise above 2.00 and usually stays below 1.00. When I had another board running, which was PERL based, it was not uncommon for my load average to go above 10 (and sometimes far higher) during peak traffic times.

I do suggest that you read up on the PHP/MySQL performance suggestions here and be ready to modify your my.cnf and php.ini files if they are not set up for optimum performance. The only minor change I made was on the first day I was using vB. I decided not to update the MySQL config until after testing it stock. It didn't take long to realize that the max_connections really did need to be upped. Luckily, I had already copied the config of a user here and I simply uploaded the my.cnf file, restarted the MySQL server and I haven't had a problem since. If your host has already tuned MySQL, you won't even have to deal with that much!

Here's a link to the my.cnf file that I am now using:
http://vbulletin.com/forum/showthread.php?threadid=1067