What is this message board's hardware platform?

This is not about the administration of the board but simply a factual, general geek hardware question which is why I’m posting it here. Move if you must mods, but I think the question is possibly of general interest.

If it’s not a state secret what is the specific hardware and software platform that this board is run on. ie OS, CPU type and speed, disk size, RAM memory, motherboard etc.

Just curious.

Hey, I just looked this up for somebody in ATMB. Wow, it’s a Miss Cleo moment! :smiley:


Does that help? There’s probably a lot more stuff in the ATMB Archives, if you Search under jdavis. That’s practically all he ever posts about. Strange, he never seems interested in our discussions of naked Jello wrestling…

I believe the server was updated to 1 GB of RAM recently, which was said to be responsible for part of the speed increase.

Along the same lines… What database is it using, and OS was asked, but not answered yet.

vBulletin uses Apache + mod_php and a MySQL database. Don’t know what OS; I’d guess either Linux or BSD.

oops, found it is using MySQL in the linked thread upon closer inspection.

A HUGE boost in throughput could be realized by simply switching to a true RDBMs engine.

still no work on OS.

According to Netcraft, it’s Red Hat Linux. Netcraft sometimes reports other varieties of Linux as Red Hat, and that could be the proxy or load balancing server, but I’d say it’s safe to assume the boards are running on some flavor of *nix.

This is more of an ATMB thing. I’ll move it over there.

First off - MySQL is no slouch in the performance arena.

(please don’t take this next point personally, by the way)

Second - you would not believe how many times over the last 1.5 years I’ve seen people say similar things, about how “easy” these things are. Somehow, no one ever seems to be able to actually do any of the work, they tell the SDMB how easy it is for someone else to do it.

This is aside from the fact that the vBulletin software only supports MySQL, and has no solid plans to support any other database engine. And this is also aside from the fact that the Reader has no $$$ for its tech staff to even implement some simple things I have offered to code myself for the SDMB. And this is aside from the fact that due to security reasons, very few people will be writing code or making changes that impact the SDMB. And, this is aside from the fact that as a company, for any major effort the Reader would most likely need to issue an RFP for the database work, then go through a proposal screening process, and come up with a set of terms and conditions that can specify consequential damages should the SDMB be down or suffer from erratic problems due to the switch to the “far superior” solution.

And, this is aside from the point that the speed issue may not even be related to anything that would be solved by a database change. No one is really sure what exactly would be the benefit. And considering the fact that the Reader loses money daily on this site, what is their business case for spending more money for a dubious benefit?

Maybe you have a good plan. Maybe you are a database Jedi Master. If so, I suggest you submit a detailed proposal in ATMB of what exactly you would do to convert the database, along with a testbed analysis of the speed increase as a proof-of-concept. Seriously - maybe if you have some good ideas, Jerry the Tech God will be able to do something to make things faster. And I for one would always be interested in seeing what could make the Board faster.

vBulletin only supporting MySQL is a rather large obstacle to overcome. As it is written in PHP, it would be job, but a doable job, to covert it to run on another database. I am sure I could do it myself even. That would cause another problem. I assume they get some support from vBulletin. Doing that kind of change would probably end all that and put updating with new versions or patches to vBulletin out of the question.

As a matter of fact though, I am a Jedi Master with databases.

One of my friends is running a vBulletin board. Maybe I a could write a port for him that runs obdc along with some admin pages for moving existing forum data from MySQL to the new database. Get it all running and tested and offer that up.

The biggest problem with the port is the way PHP supports MySQL… it is destinctly different than the way it handles other databases. In fact it has a seperate command set (function list) just for MySQL.

My gripe with MySQL is in its performance with alot of concurrent connections.

vBulletin support is provided primarily via their Forums in their web community. I do not think that the SDMB has any extra support contract with vBulletin, and Jerry seems pretty knowledgeable about it.

Well, I am running a vBulletin Board too (click on the below this post to see where), but I do not wish to risk changing anything that major at this point. I have implemented several hacks, however, and have even written a couple of my own unique ones. But my main problem is bandwidth…

I think in this case it’s actually one freeware community supporting another, and a lot of people like to link php and MySQL for that reason alone. Out of curiosity, what database product would you recommend over MySQL?

Well, I’ve been thinking on this one over the weekend.

Considering price and all, SQL Server would probably be the best choice.

Probably another problem is PHP itself. Don’t get me wrong… I LOVE php. It is very flexible, and easy to write useful stuff in. Designed for very high performance under many concurrent users it isn’t.

I guess my plan would be this. Split the system, into two machines.

Keep the current machine as a SQL machine. Buy a cheep ($2000) off the shelf 1.7Ghz box. Use the high clock rate to parse PHP in a hurry, use the old box with all its memory to handle the database efficiently. Also, the critical data is all in the database, the old box with its raid/mirror set up is the perfect one all the way around.

Even, if the cheap (non redundent) box was shot with a shotgun, it would take only minutes to prepare another replacement box. Just drop a copy of the scripts on another php capable box, and off you go… (ok, I know it is a bit harder than that, but not much) The point it, you don’t need a bulletproof box for the php engine. Keep it cheap and go for a high clock rate.

From an Oracle DBA point of view - the comparisons I have seen between Oracle and MySQL suggest that the Oracle advantages are not so much in speed (on the same hardware) or price (obviously), but in the increased robustness Oracle brings to transactions and recovery, and Oracle’s scaleability to large volumes of data.

As far as suggestions on redesigning the hardware/software, though your efforts are much appreciated, scotth, my impression is that the Chicago Reader does not wish to commit the financial resources (of which the hardware would probably be a small portion, staff hours are what adds up) to significantly modify the SDMB setup.

I am not sure how I walked into discussing coming up with a solution myself. I just merely wanted to comment that MySQL seemed a poor choice to handle lots of concurrent users. But, I am starting to back off of my thinking somewhat with my MySQL. It has been a long time since I had used it. Looking at their site, it appears MySQL has grown up quite a bit since the last time I looked at it.

My memory of MySQL was that to perform an update or insert on a table, it had to do a whole table lock during the operation instead of row level locking. This cause lots of performance problems when I dealt with it before. It looks like this might have gone away, maybe someone can clear me up on that. If it isn’t different today, how does that not cause a big performance problem on the board?

However, thinking about all of this has given me ideas for a very ambitious project. That would be writing an entire vBulletin compatible server in E/SQL C++. This would be writing the http server integrated with message board in it. Each page would be a C++ class. The perfect thing for some HUGE performance, horrible development cycle though.