一. 先看最新一期的排名（2019-10-15）

观战地址

https://www.techempower.com/benchmarks/#section=test&runid=8aaf581a-45f8-4d19-bb49-95c7900b8ce3&hw=ph&test=plaintext&l=zik0vz-v

plaintext排名

json排名

看完排名后，是不是觉得t-io的性能也不过如此？plaintext排在前列，但json就排得很靠后了，正所谓外行人看热闹，内行人看门道，这里我就来分析分析一下t-io的性能损耗都去了哪

二. t-io性能损耗分析

1. 完整的监控项管理

t-io一直聚焦解决业务疼点，而流量监控是业务疼点中的一部分，t-io的监控是所有网络框架中做得最全面的（没有之一），下面几张截图充分展示了t-io监控的全面性，但监控带来的代价是性能的极大损耗！有人会建议t-io做一个开关来控制要不要监控，这个提议表面上看没有毛病，但实际上并不具备可操作性，因为监控数据会增加中间变量的产生、统计结果的计算与判断、程序运行轨迹的变更，而要避免这两者带来的性能损耗，你设置一个监控开关是没什么用的，必须有两套差异化极大的流程程序来运行才行得通（即打开监控时走流程A，关闭监控时走流程B），内行人知道，这样做一是工作量大，二是没有实际的意义（除了TFB榜上会更漂亮些），下面看几张t-io的监控字段吧

通道监控项

端口监控项

IP监控项

2. 完整的轨迹回调接口

t-io提供的轨迹回调口子，是相当全面的，有了这些口子，业务侧想玩啥就很方便了。然而这些口子会增加中间变量的产生、统计结果的计算与判断、程序运行轨迹的变更，进而间接影响了t-io的性能

3. 如履薄冰的底层保守策略

t-io的底层代码，在处理程序时，一步一个考虑异常，无意间就多了许多try-catch和if-else这样的语句，这个对性能会有极少的损耗，但却可以大大保障底层程序的稳定性和容错性，大大降低了因为“他人”的错误导致程序不可用的风险

4. 风控程序对性能的影响

风控程序目前对性能影响基本可以忽略，但仍然存在，许多网络框架根本没有任何风控，完全甩锅给业务

5. 功能的完整性对性能的影响

t-io内置提供了阻塞发送功能、同步发送能力，这些都会增加t-io内部实现逻辑，间接影响性能，但这些影响在TFB这种级别的性能PK中，目测可以忽略

此处也有一个疑问，不清楚还有哪些网络框架提供了这些发送能力？

t-io的异步发送都是Tio.sendXxx()，阻塞发送都是Tio.bSendXxx()，同步发送是synSend()，使用极其简单！

三. 客观、坦诚、公正地看待TFB排名榜

作为极具知名的性能测试和PK大平台，TFB上的排名的确会左右架构师对技术框架的选择，但大家不应盲目的只看性能这一单一维度，框架的扩展性、功能、容错性、稳定性、生态、成功案例、社区活跃度、易用性都是架构师需要仔细把关的！

TFB上，很多框架放上去PK的代码，本身并不具备实战能力（军事演习和抗美援朝两者的区别，大家脑补），有的框架甚至连HTTP协议都没怎么实现，譬如不支持cookie、不支持cache、不支持post、不支持文件上传等（有兴趣的可以挑几个国产框架自己去review代码）

四. 结束语

t-io是把TFB当作一个测试工具，用来提升t-io的性能和稳定性（TFB上有error率指标），至于排名，作者关心，但不会因此而“纠心”，更不会为了提升排名去弄虚作假、偷工减料、甚至变更程序主流程！