Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: rogerd
I looked at a few of the commercial and even open-source BBS, or community forum, packages out there. But I wasn't very satisfied. Speed was almost always a problem. The response of the system is not fast enough usually, and it couldn't have been the server because it is the same experience on multiple websites that use the same BBS, for instance, especially when compared to bestBBS here.
The fastest BBS I've used so far is this one, bestBBS, I'll give WW that. I found a BBS that is faster, but I think it has limitations, and it's too text-based. It's called DayDream BBS [daydream.iwn.fi]. It is indeed super fast, because it is programmed entirely by assembly language, I think. However, it doesn't look very practical or attractive, yet, besides I wouldn't know how to administer it or where to find someone who can administer it.
Now I know that bestBBS may be available for purchase soon, but we don't know how soon.
So my question is: what are my best options to have a super fast BBS on my website today? Speed is my number one priority, because the vast majority of its users will probably be 56k and maybe lousy lines, too! We're talking about developing countries probably.
However, the second requirement is absolutely indispensable, which is a bilingual RtL capability. I mean the BBS should make it easy for its bilingual users to click a button to compose, and make their topic appear, from right to left, if they need. Because this BBS will be targeted towards a bilingual community, whose languages will be English and another Eastern language like Farsi, Arabic, Hebrew, and Urdu.
Then there are other important requirements, but can very well be overlooked, at least for a while, if the first two requirements are perfectly met. The rest of the requirements include: each post or topic should be indexable by search engines, and, of course, all the posts should be easily and quickly searchable intrasite or within the site.
I believe that also this should have a great impact on the speed of the BBS, but I'm not sure so please correct me if I'm wrong: I'm basically thinking that the posts should be text-only, with minimal Style Codes, just like here in WW. And, of course, without any avatars or so.
So to summarize, awesome speed, bilingual RtL posts & viewing, indexable, searchable, text-only & minimal style codes. What are my best options?
And if in-house programming is an option for us, is it actually practical to try to program a BBS from scratch using assembly language so it can be super fast, like those guys who developed DayDream BBS? And would this make administration hard later on? Besides the hosting? What's the difference between developing a BBS that way, and developing it using PHP and MySQL, for instance?
I would really appreciate it if someone could give a fairly detailed answer and information, or maybe even a few of the excellent members here can compliment each other's answers, hopefully. Thanks for anyone taking the time to help and give information.
Second, are you concerned mainly about the speed of reading, i.e., delivering forum pages? Only a few percent of your pages are likely to be new threads or new posts. Some software creates static HTML pages for each thread, and page delivery can be very quick. (This approach has some major limitations, though, and I wouldn't recommend it for a high volume board.)
To answer the first question, I'm concerned about speed not exactly because I want things to be snappy. But, as a forum user myself, I do find it a bit annoying when I, for instance, can see a lot of the text of the posts already, in a certain thread, yet the content still has to shake right and left, and things have to be flashing for a few seconds, until all the graphics of the page have finished downloading, and all the cool avatars have also managed to make it from wherever they are, whether the same website or personal servers of the users.
I do expect a fairly heavy load on those forums. The average number of "threads" or topics within any section may be 1000 right now, for instance, and one of the sections has 70,000 "replies" for about 1400 threads. I know WW gets a lot more than this, but I'm not talking about the top forums of the world on my side.
What I want is for someone who is going to click a certain thread, not necessarily to read everything, but to scan quickly and see if he/she wants to actually read the details, to be able to do this multiple times with multiple threads, and have the page of each thread appear very quickly in front of him/her. Then, when he/she clicks another thread, they don't have to wait for 5 seconds until the server responds or manages to extract the data of the thread from the database or whatever.
However, I do trust what you said about the PHP and MySQL mix, with light pages and plenty of server. I'm very inclined and biased already to believe this, because that's what I'm dreaming my best solution will actually be. However, I'm not romantic. I would most definitely go for another solution if it is obvious for me that it will serve my purposes better.
As for your second question, I cannot claim that I fully understood it. I do hope I partially answered it at least in my previous answer. However, I don't know if your question implies that the server or BBS can treat old threads in a different way than it treats new threads. If this is case, then I'm definitely interested in hearing a bit more details about this. And from your experience, I presume that if this is possible, then it is recommended that we do it, since you mentiond that is not very likely old threads are going to be read that much.
You also mentioned that creating static HTML pages of each thread is not very recommended. What does WW here do? I thought that's what it does.
What are the problems or limitations of this method?
Thank you very much again.
Forum software that generates static pages seems to be fairly uncommon these days. One major drawback is that it's not flexible - you can't offer different styles, vary the number of posts per page, etc. If you make a change to the page layout, you have to regenerate thousands and thousands of pages. On the plus side, even if your scripting or data goes haywire, the pages are still there to be read.
I didn't understand why you'd have to regenerate thousands of pages, though. If you're using PHP, for instance, can't you always "include" those static pages? Don't you mean by static pages: flat files?
Like for instance, if every thread is going to have its own static file, as a simple text file with only rare occasions of minimal "Style Codes" like the ones here on WW, then using PHP's include function, plus CSS for styling, can't you display those static pages within other PHP pages and styled, too?
The flat file approach can be fairly quick. As far as I know, that's what BestBBS uses. The forum here handles massive traffic and delivers pages very quickly - that's due to a combination of light pages, good coding, and server setup.
The general trend in forum software seems to be PHP/MySQL on the Linux side and ASP/ASPX for Windows.
I have a lot to study about PHP and MySQL anyway, because I can't quite grasp the difference between static pages and dynamic ones for the topics. You explained well, though, and that's why I figured that the problem is not in what you're saying, but in my very limited understanding of the details of how PHP works with MySQL databases and with XHTML files or includes. For instance, I was thinking, "Why doesn't this topic have its own static file, for instance, and this static file gets PHPatically included in an HTML file when someone clicks the link of this topic, along with the 'reply to this topic' link (http://www.webmasterworld.com/edposts.cgi?action=reply&forum=103&discussion=247), which can also be PHPatically included, and when the administrator wants to stop posting, or when posting has to stop after a period of time automatically, PHP stops including the 'reply to' link anymore."
Well, as you see, I was wondering with questions that may sound smart to me, but I quickly remember that I don't even have enough knowledge in PHP to really know if what I'm saying is applicable or practical at all. :)
Still, thank you for everything. :)