How much bandwidth you think these servers can handle?

Statistic content (html, jpg, gif images).

Server I specs:
1.26GHz PIII
1GB RAM 133Mhz
36GB HDD
100Mbps NIC
Red Hat Linux 7.3

and

Server II specs:
1.26GHz PIII
1GB RAM 133Mhz
36GB HDD
100Mbps NIC
FreeBSD 4.6

thx
ps. running apache (no php/perl module) of course

Ive tried to get answers similar to this concerning similar servers, it appears that there is no true answer to the question, or at least no true formula for figuring it out.....

I guess trial and error would be your only answer.

well, I see what you mean... I should set-up test environment and try it out ;)

I'm not sure about the Linux box, but I expect the FreeBSD box should be able to push a solid 30 Mbps + (roughly 3 TB/day) of traffic.

Not running scripts is the first step in optimizing your traffic. Next, strip out everything you don't need from your apache processess. The biggest limiting factor in most web servers is the size of the apache child process. Since one process serves one "hit" at one time, to serve more simultaneous hits, you need more child processes running concurrently. Dividing RAM available (without apache running) by the size of your apache child process, you can get a decent estimate of your non-swap maxproc. Also, check out the scoreboard in apache to see how you're doing.

$0.02

:eek:


Translate to english please!
LOL, wow... I wish i knew all that,lol.

20-30Mbit w/o any problems.

thanks for the info folks :):)

From my experience of lanning with 500 people and sending files to each other, you can do 100Mbits (10MByte per sec) very easily, It's all depends on your host and what type of service your server is going to run, if you only a files only server, this server is good enough to pull 100Mbits constantly.

If you've alot of scripting and uses your database, then you'll be likely getting 30-50Mbits.

Originally posted by CoreFighter
From my experience of lanning with 500 people and sending files to each other, you can do 100Mbits (10MByte per sec) very easily, It's all depends on your host and what type of service your server is going to run, if you only a files only server, this server is good enough to pull 100Mbits constantly.

If you've alot of scripting and uses your database, then you'll be likely getting 30-50Mbits.

100Mb/s == 12.5MB/s

He will never hit 100MBps. You have to factor in TCP/IP overhead.

The memory is one of the biggest factors, you will need 1gb to break the 10mBit rates.

As Bob pointed out, how optimized your executables are and your child processes of your web server is a huge factor.

Background processes is a big factor.

Your logging technique is as well, once you get high enough logging, your going to want to minimize alot of the logging and maybe do custom logging to mySQL for minimal things.

Raw bandwidth would be approximately 10 MB/sec. If you were to correlate it to Web page hits and downloads though, it'd be less than that (due to the overhead Apache and friends have).

Yes, TCP/IP overhead is a large variance. In a lab, it is very simple to hit line-speed on a server. This also has alot to do with the fact that your response times will be in the range of 0.02-0.5 ms. In the real world, latency takes its toll on the maximum amount of traffic a server can pass. In as simple an explanation as possible... every packet sent has a corresponding response packet known as an ACK. In a sense, every packet on the internet is sent "certified mail" in this way. The computer recognizes the receipt of the ACK and knows the packet has been transmitted successfully.

Unfortunately, high latency causes a delay between when a packet is sent and when the ACK is received. In a lab where two computers are essentially connected to one another, this delay is almost non-existant. In the real world, if you have latency in the order of 200ms, (1/5th of a second, as 1000ms == 1 second) these delays add up to serious amounts of time. Again, trying to keep it simple, the sockets that are opened while these packet transmissions are happening stay open throughout the entire transmission. This results in more overhead, and an overall reduction in the amount of traffic your server can pass.

Knowing this, you see some companies offering "full 100 Mbps service" on a single server, crunch all you want. In reality, you'll be lucky to exceed 30 Mbps on the server. I have a finely (finely) tuned server (P3 800 with 1 gig RAM) able to pass about 60 Mbps with FreeBSD. However, if you want any functionality beyond HTML and images, expect that number to drop even with a more powerful server.

Does anyone have real-world results on what a Dual P4 2.4 Xeon with 2GB RAM+ can sustain?

$0.02

As for protocol overhead, it is part of the bandwidth monitored when someone is checking their graphs to see how they are doing. Nobody thinks of network traffic in terms of megabytes per second--it is always measured and referred to in megabits per second. Many people carelessly toss around capital B's (MBps vs. Mbps) but in truth, Mbps is the way to denote megabits per second. If your server is capping a 100 Mbps line, you're doing quite well despite the cross-talk arping, encapsulation, and header overhead. I'd definately say you're getting your money's worth. :)

$0.02

60-80 Mbps, I think. Of course you can hit this value only if all your content can be cached in memory.