SUMMARY: 100 Mb Ethernet port needed

From: Richard Zinar (
Date: Mon Nov 16 1998 - 20:27:08 CST

   Below is my original query, and the responses I received.
   Thanks to all who responded ...

                                  Richard Zinar
                                  Jet Propulsion Laboratory
                                  Pasadena, CA 91109

> We're trying to decide whether or not to allocate a 100 Mb
> switched port to our Web server (it's currently using a
> 10 Mb switched port).
> Can someone suggest what metrics I might monitor to determine
> whether the machine's network interface is a bottleneck (or
> approaching that stage), and so would benefit from the higher
> port bandwidth?
> I'm considering installing the SE Toolkit to see what information
> it provides, but if anyone can suggest either built-in OS tools
> (e.g., netstat) or Web server log/error file messages which would
> provide insights, I'd appreciate hearing from you.
> For what it's worth, the machine in question is an Ultra 10
> running Solaris 2.5.1 (with an hme interface), and is running
> Netscape Enterprise Server 3.5. The machine is pretty much a
> dedicated Web server; in particular, it's not an NFS server.

<> (Todd Fiedler)

   So, do you have 10Mbps of bandwidth to the internet? If you do not, a
   100Mbps port will not really do any good. If you happen to blessed with
   T3 or better connectivity, and your server is handling more than 30k or
   40k hits per day, a 100Mbps card will definately help.

<> (Charlie Mengler)

   From my perspective the answer would depend upon whether the majority of
   the folks accessing this webserver were internal employees or external
  "customers". It would also depend upon the type of data being accessed &
   how much processing, if any, was required to collect & format the data by
   the webserver system.

   The ethernet pipe to the webserver could be the resource limiting factor
   in total throughput or it might not be the bottleneck. Without having
   detailed throughput data measure at each link in the chain, you can't
   conclude whether a bigger pipe will make response time faster or more
  "concurrent" hits on the web.

<> (Kelly McDonald)

   We found a good program called ntop which will provide stats on network
   interfaces. I don't have the URL but I am sure you can find it on the net.

<> (Francis Liu)

  `netstat -i` and `perfmeter` should be sufficient. I use perfmeter for a
   rule-of-thumb. If perfmeter maxes out then that suggests that your
   interface is too busy.

<> (Sandesh Kubde)

   Check your collisions by #netstat -i. These collisions should not
   exceed 5%. If the collisions are increased, the bandwidth will come down.

<> (Jeffrey Keyser)

   Using netstat -i, divide the number of outgoing packets by the number
   of collisions on that interface. If this number is greater than 5 percent,
   upgrade to the 100Mb port.

<> (Grant Schoep)

   What type of switch do you have? If it's a managed switch, you can telnet
   to the switch and monitor the port that your webserver is on. If its load
   or utilization is over 20 percent on average the 100meg port may be a wise
   choice. But then, what is the load of your other 100 meg ports. I mean, if
   you need to steal that 100meg port from something else, make sure your not
   taking it from a machine that needs the faster port. If you need to do
   this. Just login to the 100meg switch. And look how many packets each port
   has transmitted, since last reboot of the switch. The note the port with
   the least amounts of packets. Then log into your 10meg switch and look how
   many packets the webserver's port has transmitted. If the webserver is
   higher than some of the ones on the 100meg, switch it. The packet size is
   the same between 100 and 10 meg.

   Metrics aside, if the machine is solely a webserver, 10 meg is probably
   just fine. Is it a public webserver? If it is, 10megs is probably way over
   what your internet connect is anyways. A full T1 is only 1.5 megs.

<> (Dave Edick)

   If there's one thing Netscape Enterprise is good at, it's generating usage
   stats. Try going into the admin server (yes, the web admin gui) and choose
   Server Status, then Generate Report. It'll generate a detailed usage report
   from any of the log files on the server. Among the things that it reports
   are the number of hits and bytes sent during the top 5 one second, one
   minute, and one hour periods. That should tell you whether you're maxing
   out on bandwidth.

<> (Aaron Lineberger)

   If you have SNMP set up on the machine you can monitor the traffic through
   the interface using MRTG:

   Here's an example of it being used to monitor a switch port, but you can do
   the same thing for a SUN ethernet interface.

<> (John Stoffel)

   Well, who are the main customers for your web server? If they are
   external people, what is your network link to the internet? No sense
   in getting a 100mbs port when you only have a T1 link (1.544 mbs).

   It's been a while for me since running a web server, but if you see
   lots of error messages about dropped connections, that could be a
   clue. Look in the web server access.log file.

   For general system health, look at 'top'. For network health, you can
   do a simple 'look at the lights' on the switch to see how busy it is.
   You'll generally need some type of SNMP software to measure how busy
   the port is. I personally like 'mrtg' for it's graphing capabilities,
   but it's more of a trend analysis tool, not something to say whats
   happening right now.

   It almost sounds like it's an internal server, but I could be wrong.
   How much memory does it have and is the system low on memory? Does
   the 'sr' column in 'vmstat' output show that you are swapping alot?
   If so, try adding memory to the system.

   And of course, more details on web server setup, the type of customers
   you're serving and where they are located network wise would help pin
   down the bottle neck. It could very well turn out to be completely
   outside your control to fix.

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:52 CDT