就像延迟和吞吐量是硬盘驱动器的限制因素一样，延迟和带宽(实际上和吞吐量是同一回事)也是网络连接的限制因素。对于大多数应用程序来说，最大的问题是延时。典型的应用程序都需要传输很多很小的网络包，并且每次传输的轻微延迟最终会被累加起来。

        运行不正常的网络通常也是主要的性能瓶颈之一。丢包是一个普遍存在的问题。即使1%的丢包率也足以造成显著的性能下降，因为在协议栈的各个层次都会利用各种策略尝试修复问题，例如等待-段时间再 重新发送数据包，这就增加了额外的时间。另一个常见的问题是域名解析系统(DNS) 损坏或者变慢了。

        DNS足以称为“阿基里斯之踵”，因此在生产服务器上启用skip_ name resolve 是个好主意。损坏或缓慢的DNS解析对许多应用程序都是个问题，对MySQL尤为严重。当MySQL收到一个连接请求时，它同时需要做正向和反向DNS查找。有很多原因可能导致这个过程出问题。当问题出现时，会导致连接被拒绝，或者使得连接到服务器的过程变慢，这通常都会造成严重的影响，甚至相当于遭遇了拒绝服务攻击(DDOS)。 如果启用skip name_ resolve 选项，MySQL 将不会做任何DNS查找的工作。然而，这也意味着，用户账户必须在host列使用具有唯一性的 IP地址，"localhost" 或者IP地址通配符。那些在host列使用主机名的用户账户都将不能登录。

        典型的Web应用中另一个常见的问题来源是TCP积压，可以通过MySOL的back 1.og选项来配置。这个选项控制MySQL的传人TCP连接队列的大小。在每秒有很多连接创建和销毁的环境中，默认值 50是不够的。设置不够的症状是，客户端会看到零星的“连接被拒绝”的错误，配以三秒超时规则。在繁忙的系统中这个选项通常应加大，把这个选项增加到数百甚至数千，似乎没有任何副作用，事实上如果你看得远一些，可能还需要配置操作系统的TCP网络设置。在GNU/ Linux系统，需要增加somaxconn限制，默认只有128,并且需要检查sysel的tcp max syn back _log设置(在本节稍后有个例子)。

        应该设计性能良好的网络，而不是仅仅接受默认配置的性能。首先， 分析节点之间有多少跳跃点，以及物理网络布局之间的映射关系。例如，假设有10个网页服务器，通过千兆以太网(1 GigE)连接到“网页”交换机,这个交换机也通过千兆网络连接到“数据库”交换机。如果不花时间去追踪连接，可能不会意识到从所有数据库服务器到所有网页服务器的总带宽是有限的!并且每次跨越交换机都会增加延时。

        监控网络性能和所有网络端口的错误是正确的做法，要监控服务器、路由器和交换机的每个端口。多路由流量绘图器(Multi Router Traffic Grapher), 或者说MRTG,对设备监控而言是个靠得住的开源解决方案。其他常见的网络性能监控工具(与设备监控不同)还有Smokeping 和Cacti 。

        网络物理隔离也是很重要的因素。城际网络相比数据中心的局域网的延迟要大得多，即使从技术上来说带宽是一样的。如果节点真的相距甚远，光速也会造成影响。例如，在美国的西部和东部海岸都有数据中心，相隔约3000英里。光的速度是186 000英里每秒，因此一次通信不可能低于16毫秒，往返至少需要32毫秒。物理距离不仅是性能上的考虑，也包括设备，之间通信的考虑。中继器、路由器和交换机，所有的性能都会有所降级。再次，越广泛地分隔开的网络节点，连接的不可预知和不可靠因素越大。

        尽可能避免实时的跨数据中心的操作是明智的"。如果不可能做到这一点，也应该确保应用程序能正常处理网络故障。例如，我们不希望看到由于Web服务器通过丢包严重的网络连接远程的数据中心时，由于Apache进程挂起而新建了很多进程的情况发生。

        在本地，请至少用千兆网络。骨干交换机之间可能需要使用万兆以太网。如果需要更大的恭富，可以使用网络链路聚合:连接多个网卡(NIC)，以获得更多的带宽。链路聚合本质上是并行网络，作为高可用策略的一部分也很有帮助。