Add preview docs on the new project turms-benchmark

turms-docs/src/for-developers/testing.md

@@ -16,8 +16,12 @@
 
 2. 单机与分布式的压测结果也完全不一样。甚至Turms服务端还将支持：在单机部署场景，Turms服务端支持Unix Domain Socket，而无需走TCP连接。
 
-综上，如果Turms只想写个好看的压测报告，Turms服务端可以不做任何数据存储、不保证消息必达、不对日志做任何采样，对所有数据都进行长时间的缓存，其最终的吞吐量自然很高，但这样的压测报告就如同空中楼阁，没有多少真实场景会使用这么一套配置。这也是我们做中大型软件开发的人不太愿意直接提供简单压测报告的原因。
+综上，如果Turms只想写个好看的压测报告，Turms服务端可以不做任何数据存储、不保证消息必达、不对用户请求进行日志采样，对所有数据都进行长时间的缓存，其最终的吞吐量自然很高，但这样的压测报告就如同空中楼阁，没有多少真实场景会使用这么一套配置。这也是我们做中大型软件开发的人不太愿意直接提供简单压测报告的原因。
 
 另外，不仅是Turms，其实对于任何技术方案来说，我们在看它或快或慢的时候，主要是为了探究“它什么这么快/慢？”。举例来说，我们在研究JVM为什么会占这么多内存时，如果我们只看到了Java极为冗余与普遍的对象头时，我们会感叹“原来是冗余设计问题，难怪占这么多内存”，但如果我们又看了JVM对Code Cache的设计与使用，我们又会感叹“原来是空间换时间，难怪占这么多内存”，评价方向截然不同。归根到底就是外行看热闹，内行看门道。Turms为了方便用户看其中的门道，因此文档都写得比较详尽，方便用户自行评测Turms适不适用于自己的应用场景。
 
-尽管Turms没计划提供压测报告，但我们后期会写一套基于Kotlin的DSL帮助用户编写压测脚本，甚至是像nGrinder那样一套更为复杂的分布式压测平台。
+### turms-benchmark项目（预览文档）
+
+尽管Turms没计划提供现成的压测报告，但我们近期会写为Turms服务端定制一套分布式压测平台。该平台的UI展示与报告分析会由turms-admin负责，而节点管控与任务执行分别由turms-benchmark中的Controller节点与Agent节点负责。
+
+特别一提的是：Turms之所以能快速定制与开发众多平台，也得益于我们在[基于Turms做二次开发的原因](https://turms-im.github.io/docs/for-developers/redevelopment.html#%E5%9F%BA%E4%BA%8Eturms%E5%81%9A%E4%BA%8C%E6%AC%A1%E5%BC%80%E5%8F%91%E7%9A%84%E5%8E%9F%E5%9B%A0)提到的“可控性。Turms项目100%开源，并对很多基础中间件进行了自研，保证了底层技术的可控，避免了项目后期发展动力不足”，因此我们做新项目不会受制于第三方依赖，动力十足。