| 1:59 am on Jan 18, 2005 (gmt 0)|
1. Image files? Logos, etc. Increase bandwidth.
2. CSS to cut down on page/file size, bandwidth, processing.
3. HTTP compression? Less bandwidth more processor.
4. Database or flat file?
5. Signatures allowed? The more fluff the more bandwidth, etc.
6. Peak vs. off-peak performance?
7. Instant imbedding of thread within reply thread? Bits and bytes.
8. Spam patrol? Cuts down on all variables.
The less fluff the less bandwidth and the greater speed, all things equal.
I'm certain others will chime in.
| 2:44 am on Jan 18, 2005 (gmt 0)|
Based on what I've seen of vBB, to have close to a thousand users online and maintain reasonable performance, you'll want at least a dual Xeon with a couple of Gigs of memory. Much past that and you'll be moving into cluster range.
If your forum isn't image-laden, keeping things under 1000GB shouldn't be too difficult. Bandwidth is definitely under your control - when I started a new high-volume vBB install a few months ago, one of the first things I did was strip images, text, and code from the major templates to keep the pages as light as possible. Even a "light" vBB page is fairly heavy. If you are doing a photo-forum, though, you are likely to run into some major bandwidth usage.
There are some pretty good discussions at the official vBB forum of how to minimize CPU usage and bandwidth.
Since your forum is new, though, you could definitely start off with a cheaper server and upgrade if it takes off.
| 4:14 pm on Jan 18, 2005 (gmt 0)|
2 bits of advice related to server performance I can offer from my own experience:
- *definatly* get more than 512Mb Ram or your system will be disk-swapping all the time especially if your database is on the same server as your webserver. go for 1Gb at a minimum. If you cannot get more ram for whatever reason (or find 1Gb still isnt enough), build MySQL in a memory restricted way, here is my configure line for mysql4 on a RHEL box:
|./configure --prefix=/usr/local/mysql4 --with-extra-charsets=none --enable-thread-safe-client --enable-static --disable-largefile --with-mysqld-user=mysql --without-debug --enable-assembler --without-query-cache --without-extra-tools --without-docs --without-bench --with-charset=latin1 --without-innodb --disable-shared --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static |
And I pass these parameters to mysqld when starting:
|/usr/local/mysql4/bin/mysqld_safe --user=mysql --datadir=/usr/local/mysql/data \ |
--key_buffer_size=512K --sort_buffer_size=16K \
--table_cache=32 --read_buffer_size=8K \
I get fairly good performance with those settings on a busy phpbb forum on a server with 512Mb RAM, but your milage may vary.
- Try and get 2 IP addresses with your server and serve all your images from a lightweight http server such as thttpd or boa (im using boa at the moment). They use a *lot* less memory and let you keep your apache->php->mysql setup dedicated to the code stuff. You will however need a fair bit of knowledge to get this to work, AFAIK there are no "published" hacks for this sort of thing for VB.
| 6:06 am on Jan 31, 2005 (gmt 0)|
your mysqld parameters are FAR too low, for your 512M box try:
--key_buffer_size=128M --sort_buffer_size=2M \
also add low_priority_updates=1
trust me... ;)
in general you can serve about 30M page views per dedicated 2.8GHz Dual Xeon with 2-4GB RAM... so for a small celeron that would be about 7M page views/mo or so... if:
- you optimize certain forum settings (e.g. mass update of view counters every 5 minutes instead of doing that instantly)
- use MMCache php precompiler (free)
| 3:22 pm on Jan 31, 2005 (gmt 0)|
I would second the recommendation for a dual-processor machine. That's what I use, even though I don't have close to that much traffic. It's overkill for me right now, but it leaves so much room for scaling up. But for the kind of usage you're describing, I'd definitely go for two processors over one. One processor can only handle one task at a time, so everything is serialized. Add a second processor and you've just doubled your throughput. Your server can now theoretically construct two dynamic pages simultaneously.
| 4:29 pm on Jan 31, 2005 (gmt 0)|
I concur with what others are saying. If you know you're going to have that many people online, go with something like a Xeon processor and a couple of gigs. You might be able to get away with a single processor to start but make sure your board is dual capable.
scsi, not sata hard drives too.
| 4:41 pm on Jan 31, 2005 (gmt 0)|
Interesting that everyone is thinking dual-CPU in this thread. Would you go single machine dual CPU over dual machine single CPU as a load-balanced pair?
| 5:24 pm on Jan 31, 2005 (gmt 0)|
Interesting question, tj. My first thought would be that a dual CPU server would be cheaper and that communication on the same board would be faster; a pair of servers would no doubt offer some redundancy in case, say, a power supply fails.
I'd be interested to hear some thoughts on this issue, and how difficult it is to configure a load-balanced pair. I.e., does the load balancing software do all the work or must the admin take special steps in installation/configuration?
| 4:12 am on Feb 1, 2005 (gmt 0)|
Well, say you have stateful sessions, then your load balancer has to be a little smarter. It gets a little more complex, while a single server is very straightforward. I do see the value in redundancy, though. Personally, a part of me just finds a dual CPU machine a bit more "exotic" and thus desireable. There's a good reason there!
| 1:31 pm on Feb 1, 2005 (gmt 0)|
Yeah, think of how they'll look at you in the local pub when you let 'em know your server is running dual Opterons with 4 gigs of RAM. :)
| 1:42 pm on Feb 1, 2005 (gmt 0)|
>700-900 people online at a time
You will need some serious fault tolerance for that much concurrency.
I wouldnt go less than 2 X xeon 3Ghz processors, and 9 drives. raid 0+1 (4 drives) for the database files and transaction logs, raid 1(2 drives) for your database server and raid 5 (3 drives) for the webserver.
| 2:07 pm on Feb 1, 2005 (gmt 0)|
|how difficult it is to configure a load-balanced pair |
I'm about to find out so I'll let you know ;-)
We opted for a load balanced pair as, actually, it was overall cheaper than the dual CPU machine with the added advantage of redundancy.
We'll have a phpBB2 forum on there. I think it's a case of setting up the MySQL DB in a master/slave relationship. I'm not 100% sure yet - we're looking at this now.
I get the pair of boxes and load balancer on Friday and we'll be running the existing single box side by side until we're happy with it, so I'll get a good chance to mess around with it.
| 12:16 am on Feb 25, 2005 (gmt 0)|
I just added server #11 to a high traffic forum site (100+ pvs/sec). Load balancing the web traffic is easy (100% software based, DNS-rr), really challenging is to keep the cluster of DB servers running... DB failover is a non-trivial task, even the fastest 15k SCSI disks get slow sooner or later... now even the internal 100mbit lan becomes a bottleneck. All servers are Dual Xeon, most with 4GB RAM, 24 SCSI disks total