I've got to build a new BBS and fatasy foot game !!!!

greenspun.com : LUSENET : Unofficial Newcastle United Football Club BBS : One Thread

My new project at work is to build a fantasy football site. It's high profile with a 1 million quid top prize.

Since I'm the head developer on the project, I'll get to make quite a few of the design decisions. Rest assured that I'll be running lots of ideas past you lot over the coming months.

First question. I've got to develop a BBS system. I figure I'll base my design on the communicata site. What's the consensus on that decision?

Nick Raphael

-- Anonymous, April 03, 2000

Answers

Nick; I wonder how many of your design decisions will be forced due to the technology decision. Do you have leeway in deciding what OS and tools you have to use, or are you forced by company policy to tread the dark path?

-- Anonymous, April 03, 2000

Do we get commission for helping with your work? ;-))

-- Anonymous, April 03, 2000

Commission - no. Immense feeling of satisfaction - yes.

Of course technology is an issue. Looks like we'll be using site- server, ASP, COM etc.

Going back to the BBS plan, the old communicata didn't categorize threads. Personally, I preferred the old BBS interface.

Thoughts?

-- Anonymous, April 03, 2000


Nick. site-server, ASP, COM etc. AAAaaaaaaaagggghhhhhh!!!!!!! What sort of traffic do you envisage? What's your hardware spend? If you are forced to tread this dark path, throw as much money as you can at a cluster of boxes running NT/SQL server.

It might then work.

Sometimes.

Or maybe not.

But at least you'll have a chance.

The 'standard' architecture for something large on NT is SS at the top, a couple of boxes handling LDAP (for MS personalisation and membership) and then a cluster of 2 boxes running SQL server. Check Compaq's site for docs. Expensive to administer though.

IMHO and long, bitter experience, you *must* analyse how much DB activity you have throughout the site; in terms of generated content, personalisation, shopping/ecommerce etc. You then have to think very seriously about what Db will handle the number of transactions. I could talk about threads, processes, database handles, locking, transaction processing and rollback, but I sense the rest of the BBS heading for the exit.

FYO, the reason why the Communicata worked so well was that it was running on SunOS, with Oracle being accessed with AOLserver operating both as the web server and DB client. That's how this site works too, only the interface is a bit more sparse.

-- Anonymous, April 03, 2000


Dunx.

That is exactly the set up. The client is rich as anything and can throw as many servers at this as we want.

-- Anonymous, April 03, 2000



OK Dunx.... how come your postings always go to the top of the thread and not to the bottom like us mortals?

It's confusing when they get out of time order!

-- Anonymous, April 03, 2000


Nick

Rich as anything client. Fine. Still need to do the DB analysis to see if it will work. Sorry for being pedantic, but I guess as project lead it's your cobblers on the block, so you don't want to be in a position where you spend all the money on huge amounts of kit/developers and when the site gets hit hard as it takes off, it falls over. At this point, clients/management come and chop your cobblers off, and you get fired. Oh and they still don't have something that works.

I take it your developers are all NT/ASP people? Got any Oracle DBAs? Unix gurus?

Check out

http://photo.net/wtr/arsdigita-server-architecture.html

The database stuff though is crucial; here's something copied out of one of Philip Greenspun's documentation

Relational database management systems exist to support concurrent users. If you didn't have 100 people simultaneously updating information, you'd probably be better off with a Perl script than a commercial RDBMS (i.e., 100 MB of someone else's C code). All database management systems handle concurrency problems with locks. Before an executing statement can modify some data, it must grab a lock. While this lock is held, no other simultaneously executing SQL statement can update the same data. In order to prevent another user from reading half-updated data, while this lock is held, no simultaneously executing SQL statement can even read the data. Readers must wait for writers to finish writing. Writers must wait for readers to finish reading. This kind of system is simple to implement, works great in the research lab, and can be proven correct mathematically. The only problem with it? It doesn't work. Commercial implementations of this scheme (e.g., Illustra, Microsoft SQL Server ) get confused and stuck when there are more than a handful of users. With the Oracle RDBMS, readers never wait for writers and writers never wait for readers. If a SELECT starts reading at 9:01 and encounters a row that was updated (by another session) at 9:02, Oracle reaches into a rollback segment and digs up the pre-update value for the SELECT (this preserves the Isolation requirement of the ACID test). A transaction does not need to take locks unless it is modifying a table and, even then, only takes locks on the specific rows that are to be modified. This is the kind of RDBMS locking architecture that you want for a Web site.

Makes sense and also works; once again in my experience.

Hope I'm helping......

-- Anonymous, April 03, 2000


Moderation questions? read the FAQ