Ok, I've now got the accelerator installed which works wonders, but I've still got a few questions.
Correct me if I'm wrong, but I assume that the Cache Hit Percentage is based off of how many hits to the board draw from the cache as opposed to having it generated from the files off the disk, and or a new post etc?
The second is where is this important? What are the implications? I know people say to keep it between 30-60%, I'm at 53% at the moment but is there a magic upgrade light that's going to flicker on at some point?
The cache hit percentage is the percent of requests that call the accelerator (ultimatebb.php)
53% is great cache percentage
There isn't a magic light that will blink about an upgrade. I think when you are getting over half a million page views a month, your host might get grumpy. They might start trying to coax you to a PHP/MySQL based board at that point. That of course depends on the number of members, topics, server, etc.
I did 3.8 million pages (14 million hits) and 42.1GB last month and my host didn't blink... but the site is growing so fast, I'm gonna HAVE to go to dedicated server... Only 3700 members, but about 1000 of them live on the site...
My cache hit % stays between 48-53%.
I can't imagine moving away from UBBS... all the time and effort I have invested in getting it just like I want it... the styles, sidebar, putting in the AdsPro software, et al...
Reckon how long I can get away with using a flat file system? I've been looking at database backend packages, but I shudder at the thought of dealing with the data conversion/transfer.
I AM concerned about my archives though... my tech archive has just over 20k threads in it now and growing at 500 threads a month... I've considered breaking it up by year, but that's make searching even less attractive to the members...
Oops... I didn't take into consideration that my webstats total would have everything included...
Right around 1.14 million for the UBBS if I remember correctly for January...
But for February, I'm up to 92,136 page views and the cache hit percentage is 48.95% (dropped some due to the cache flush after the prune/move/reindex last night).
That jives pretty close to the current Feburary web stats page:
/ubb/ultimatebb.php = 47000 /cgi-bin/ultimatebb.cgi = 45094 /cgi-bin/cp.cgi = 3207 (because of the ongoing maintenence)
Thanks for the heads up... I'm still pounding out a lot of pages though... <img src="https://www.ubbcentral.com/boards/images/graemlins/smile.gif" alt="" />
(92136 / 3.5 [3 days plus half of today]) * 30 = 789,737 estimated monthly pageviews, at a very minimum. Probably more than that...
We generally advise moving off to a dedicated server (or to UBB.threads) at around 500,000 monthly pageviews. <img src="https://www.ubbcentral.com/boards/images/graemlins/smile.gif" alt="" />
Same numbers (of course) that I got for a projected February... but it will definitely be more... the trend line is rising, and nothing "significant" has happened like a new project, car, etc. to drive the traffic lately... it always does.
I AM getting ready to move to a dedicated server (P4 2GHz, 80GB HDD, 1GB DDR RAM, and 700GB bandwidth)... It'll just take some time.
How long can I continue to use Classic on a dedicated server? I'm really not looking forward to having to transition to Threads... It looks like a huge job...
On that hardware, you'll probably make it up to about 1.5 to 2 million pageviews before performance becomes a serious issue - so up to double your current traffic.
Around 2 million a month, performance will really start to suffer. This isn't really because of the server not being able to handle the load - the design of Classic is meant to provide saftey from corruption at the expense of speed. The brutal file locking scheme in use prevents scaling too much higher without throwing some major hardware at the board... and even that will only squeeze out another half million monthly pageviews.
You should seriously consider biting the bullet right now and moving off to UBB.threads. Double the memory in the machine, tweak out MySQL, and use a caching/compiling PHP accelerator, and you can probably get to 4 million monthly pageviews on that hardware.
(For UBB.classic, the performance bottleneck is the filesystem and the number of files present in a directory. For UBB.threads, it's the database and the size of your Posts table that will rule performance. You'll probably want to keep around less than 500,000 posts to get consistantly good performance on that hardware. The problem is mainly that there's only one server that has to share the load of the database and the application. In a really ideal situation, there would be a dedicated server just for the database, and another server just for the application, but that begins to get really expensive. The TrekBBS is on the same hardware you quoted, but with only 1.5 gigs of memory. It has to be kept pruned to 400,000 posts to keep MySQL performance acceptable.)
OK... so UBB.threads is definitely in the forseeable future... How hard is it to convert the styles over from one to the other? I've not looked at threads yet, so I don't know yet...
What do you mean by "tweak out" MySQL? And what PHP accelerator would I use...
Man, I can't believe I'm even considering this right now...
The move would be better to make AFTER I'm on the dedicated server right?
Threads is a totally different animal - lots of things are done differently.
Threads uses CSS files to define colors. You'll need to manually alter the CSS in order to bring your color scheme over.
The header and footer are done in the same way as you'd expect - just put HTML in a box and hit the submit button. <img src="https://www.ubbcentral.com/boards/images/graemlins/smile.gif" alt="" />
The stock version of MySQL that will come with the server will not be configured to perform well. Some alteration of the config will be required - usually by replacing the existing config with the "mid" or "max" configs. You should probably head over to the Threads forums here at UBBCentral, or head over to ThreadsDev.com and ask about optimizing MySQL.
The generally accepted PHP compiler/cacher/accelerator is called "turck mmcache" and can be found via Google. Once again, getting more information on getting more performance from PHP would be more suited to the other boards. <img src="https://www.ubbcentral.com/boards/images/graemlins/smile.gif" alt="" />
Normally we do advise moving, then considering upgrading. Your upgrade period may be some months away, so there's no immeidate need to worry about things. Move now, and worry about things later on. <img src="https://www.ubbcentral.com/boards/images/graemlins/smile.gif" alt="" />
(Besides, the new 6.5 control panel for UBB.threads won't be out for a while, so the delay is worth it...)
My board has around 6500 members and is logging around 1.5 million page views. We are about to switch to a dedicated server, and decided to upgrade before doing so. Your sales person advised that we upgrade to the current Classic version rather than Threads. After reading this post, I am not sure if this was the correct suggestion.
6500 members isn't that much. I used to Admin a board with 13000, and UBBDEV has ~11500. The 13000 member one didn't even have the PHP accelerator enabled and it was fine on a dedicated server.
I'd go with as much ram/speed as you can afford, the faster the machine the less you'll have to worry about. Don't bankrupt yourself but try to keep it fairly high.
With that many pageviews, yes, you do belong on a beefier server, and probably UBB.threads if you wish to keep performance acceptable.
That 1.7 server sounds like a Celeron, which would not be suitable for hosting a database-based application such as UBB.threads. Insist upon a real processor, such as Pentium 4 or an Athlon.
the higher is listed as a minimum, not a maximum <img src="https://www.ubbcentral.com/boards/images/graemlins/wink.gif" alt="" /> ... If it's lower than the low then something is breaking the cache; if it's between the two you're in harmony and its normal; if it's above then you're doing osmething right or your forums are slow (new content wise).