当谈到网络服务性能的时候，很多人都会采用一些单一性的指标数据作为性能参考，如支持多少在线，能跑到多少带宽等；实际上这些单一性的指标数据并不能反映服务的基础性能，毕竟应用场景是多样性的；那更好判断一个服务的基础性能需要符合那些要求呢？接下通过各种场景测试来证实一下，服务基础性能需要关注那方面的指标数据。
为了可以得到更符合实际的测试结果，测试环境采用了10Gb的网络环境，对于一个服务端程序进行多种场景的测试，看一下服务端在各种单独指标项中性能有着怎样的表现。顺便也可以了解 一下在不讲武德的情况下把单一性指标如何做得更高来得到一个更有体面的说法。测试方法每个示例采样2分钟，看服务占用CPU资源情况。
在线并发数指标
很多时候都会谈到这个指标项，简单来说以服务支持多少在线交互来对服务的性能做一个评价。接来分别做1000,10000,100000在线的通讯交互，但不改变其总网络读写的情况下CPU损耗是怎样的。
1000连接
10000连接
100000连接
以上是三种不同在线情况的测试，虽然10万在线在控制发送有些波动，但总体IO读写和带宽都保持在对应的区间上。从三个测试结果来看其服务端的cpu基本没有太多变化，即使1000和100000差了100倍的连接数也不会引起cpu资源波动。大量在线到达某一数据量的情况的确是对系统性能产生影响的，主要是对应句柄数量巨大引起系统的管理性能问题。
带宽指标
这个指标项也经常谈，通过跑更高带宽来转化成消息处理，从而来确定服务可以处理多少消息量来突出服务性能的好坏。实际上高带宽是不是就意味着会损耗更高CPU资源呢？接下来测一下2000连接，在不改变IO读写量的情况来提高带宽吞吐看一下CPU资源的变化。
发送128字节
发送4K数据
同样的IO读写量，前者跑了70Mb带宽，后者使用了超过2Gb带宽；但两者的CPU资源使用量基本一样；所以能跑多少带宽完全取决于测试者基于什么导向来测试。
网络IO读写
说实话很少人在讨论网络服务基础性能的时候会引入这一指标，毕竟这一指标是实打实的，在一台服务器上这指标的支撑量是固定的。它和在线连接数并发带宽没有一个正比的关系；简单来低带宽也可能出现高IO读写应用，高并发在线也可以出现低IO读写。文无第一武无第二，上面两项是文而这一项就是武了！毕竟实际应用中普遍都是基于请求响应的方式，每个操作都涉及两到一个或多个网络IO写和读。
50连接高并发读写(4K)
200连接高并发读写(128字节)
这项测试中虽然都使用了低连接和最后面测试的低带宽，但在所有测试中服务端最占资源是这两项测试，而它们都有着低连接，低带宽的特性；但同样有着一个共同的特点是有着大量的IO读写，这些IO读写量都远比之前的测试要高，同样CPU使用量也是相对提高了。
总结
通过以上的多个测试相信对服务端的基础性能应用那些指标来评估有个一个大体的了解。抛开实际业务逻辑网络读写对整网络服务来说占主要性能开销，相对于同时在线数和带宽这些单一性的指标有着更重要的参考性；所以讨论这方面的内容时一定要制定一个更清晰的基础准则才能更好地去判定。
回到实际服务应用开发中思考，既然服务的网络读写是这么有限制和损耗资源，那在设计时候就尽可能合并这方面的工作，在业务可接受的情况下合并IO读写来提高效率。
现有的性能测试已经不会把同时在线或能跑多少带宽这些单一的指标用于作为性能测试的参考；在techempower的测试中没有一项测试是采用数万或数十万的连接作为测试要求，毕竟这两项已经是外部环境因素了。
