在DeepIn ♂ WCF 中曾提到WCF中net.tcp协议的特有消息序列化格式。这个格式是微软的私有格式，对非微软.net客户端调用非常不友好，导致接口测试比较复杂，特别是性能测试。

因最近工作对某服务进行了大量的优化，需要通过性能测试展示优化的成果。传统上对net.tcp接口的性能测试会再搭建一个webapi站点代理测试流量，对于普通写库业务来说，单次接口请求可能时长长达100ms，webapi还是可以有效传导压力的。但是对于我这个查询类的服务来说，单次接口请求时长仅2ms，webapi这层代理不堪重负，不仅序列化反序列化占用大量CPU，还有到net.tcp短链的端口限制，导致压测数据完全不理想。（webapi的CPU使用早早到达90%，然而服务的CPU使用率还只有10%）虽然可以横向扩展webapi，用负载均衡的方式扩展webapi，但这样颇费周折，也没有那么多测试机器资源。

常规性能测试工具以Http请求为主，比如Apache Benchmark、Wrk。在某天突然想起Jmeter可以发起Tcp请求，就拿来试了。 但在实际使用的过程中还是有很多问题。

首先用wireshark抓包，通过对多次请求的包内容观察，发现有一段16字节长度的部分每次都会变化，直接当做GUID处理了。

在jmeter创建的Tcp Sample中如图进行输入，输入org.apache.jmeter.protocol.tcp.sampler.BinaryTCPClientImpl，选用二进制Tcp客户端。Text to send则输入16进制内容即可。其中使用了变量${GUID}，这个需要增加一个JSR223 PreProcessor，在vars中put变量即可。

然而经测试，服务端直接reset了这个链接，说明报文内容有问题，经对抓包内容进行观察，发现还有一个类似于打开通道的请求，加上后则可以进行正常调用了。还要注意一定要设置End of line byte value，不然Jmeter无法判断请求已结束，则会一直等待。

最终测试下来，在测试环境的4核虚拟上QPS达1200，在生产的24核物理机上QPS达7700。比优化前数据4核QPS280，24核QPS600的数据分别提升了4倍和13倍。