This tip originally appeared on SearchNetworking.com, a sister site of SearchSMB.com.
If you've been having performance problems with your server, you may be able to ramp up network throughput by taking a deeper look at your driver configuration.
Suppose that you've upgraded the hardware and installed gigabit Ethernet and the fastest disks you can find. Your processor and memory and network utilization are low, but your network throughput is still not quite where you think it should be. You might want to start looking a little deeper into your software -- specifically, tweaking your drivers.
One place to look is your hardware interrupts. If you're using Windows Server, you can open the Performance monitor, and then the Processor object. Look for a counter named something like "Interrupts/sec." When you're sending packets as fast as you can, look to see if this counter hits a plateau it never exceeds. You may find more detailed interrupt counters in the NIC objects.
The point, though, is that your NIC drivers probably have a setting called something like "Max Interrupts per second" which obviously can limit your throughput, since each network frame requires an interrupt. If your server is serving lots of little files (e.g. a typical Web server as opposed to a typical file server, which would tend to send fewer large files) then you'll need more interrupts. If you're seeing numbers in the performance monitor that are close to the configured "Max Interrupts per second," you may want to consider increasing this field. Its default value may be a little -- or a lot -- low for your application.
And by "consider," I mean "research carefully and fully test before attempting to implement in a production environment." Keep in mind that limiting the number of interrupts can also be a good thing (think broadcast storms and ping floods).
You'll want to test your configuration of the Max Interrupts because sometimes obscure options like these are included in the GUI for drivers, but there's no code behind it. That is, the option is vaporware and doesn't really do anything no matter where you set it. Or there may be some other consideration, like your application is more disk-intensive than network intensive, and by shifting resources to the LAN, you may experience a net performance loss if there is contention with other hardware.
