leesper

楼上两位，要不我们仨协作一下，一起做个压力测试如何？因为这方面我不太熟悉。我自己公司的远程控制系统也用了这套框架，之前有写过模拟客户端模拟发送接收数据，所以代码中有个metrics.go已经统计了以下几个数据指标： 1. 总共有多少个客户端连接C； 2. 总共处理了多少次请求H； 3. 处理这些请求累计使用的时间T； 4. 然后计算QPS = H / (C \* T / W)，其中W为工作者线程数量。

@shinwing Hi，RPC我不是很了解，我说说我自己的思考哈。我感觉你担心的是消息是不是会发生“串号”的问题。那么一般来说server和client的通信是通过它们之间建立的connection来实现的，client在connection上发送一个request，server处理完毕后通过connection返回一个response。如果是推送一个push，那么可以双方约定一个协议号或者协议名称，client收到消息的时候先检查这个名称或者协议号，根据协议号来执行相应的业务逻辑，这样是不是就可以区分了呢？我在tao框架中用的是协议号，不过这是山寨做法，更好的做法，你可以参考陈硕的这篇blog[一种自动反射消息类型的 Google Protobuf 网络传输方案](http://blog.csdn.net/solstice/article/details/6300108) 对于pingpong那个例子而言，如果返回值不只一个，我们同样可以采用协议号或者协议名称的方式来区分并建立不同的处理逻辑。 不知道我的回答有没有解决你的问题呢

@shinwing 不客气，我也是初学者

暂时还没有呢，我最近实在是忙的一塌糊涂……

@piaohailin 这个要到简书上去找找那哥们，给他留言，问下他压测怎么做的，在多大压力下发现这个问题的

@arden @piaohailin Hi all，简书上楚客提到的两个问题我今天都一并处理了，具体采取的处理方式如下： 1. 关于ErrWouldBlock问题，我觉得就算把工作者线程数量和buffered channel的size改得再高，总有撑不住的压力，所以我添加了两个新的ServerOption，一个叫WorkerSizeOption，一个叫LoadIndicatorOption。WorkerSizeOption用来调整工作者线程池大小，LoadIndicatorOption用来指定各buffered channel size的倍数（比如指定为2那么size=1024 × 2）。然后我在handleLoop中把返回的err打一个log出来，而不是直接忽略掉。如果循环调用put直到成功，会阻塞事件循环，且不知道阻塞多久能恢复，风险不可控。与其这样，还不如打印日志，让开发者知道问题，并采取措施（比如调整线程池数量或者增加channel的size），这样顺便也把WriteCloser接口的Write方法返回ErrWouldBlock的问题解决了，简单说就是“留给框架使用者去考虑”。 2. 当serverConn关闭时调用asyncWrite不会返回错误的问题的确是一个隐藏的很深的bug，这个我借鉴 楚客的方法做了修改。

你的数据包大小超过8M了？如果框架的Codec不满足你的需求，请自己编写一个，谢谢。

@robinbing123456 那就是你length字段填的代表包大小的数字不对，超过8M了

@zjs604381586 好的，我再研究一下，谢谢您！

@zllangct 我不会C#……