要得到可支撑的"最大同时在线人数"，主要做好2件事：
1、设计你的类现网压力模型
在现网真实压力里，不论压力大小如何变化，现网环境如何变化，一个游戏类型和玩法设计定型后，永远有2个压力宏观数据保持不变：a. 各接口的压力比例不变， b.玩家平均每分钟操作频率不变。因此，压力测试目标就转变成了如何模拟符合ab数据的压力。
对于a，首先从同类型游戏或者本游戏内测阶段，日志插桩，收集各个接口的调用比例；然后，将接口比例转化为场景比例，如同时会有个2%完结登陆、15%玩家战斗、20%玩家拉取好友列表、10%玩家赌博（一个手游场景例子）。
对于b，同样在内测阶段收集玩家平均操作频率。
此时有了a和b，就可以构造出一分钟内玩家同时在线的真实压力模型了。
2、用压测工具构造出符合压力模型的压力
这个可以自己写，也可以使用现成的压测工具。现在市面上的压测工具很多，但很多都是专注于TPS这个参数，不符合游戏行业压测的关注点，同时在线人数。
粘包和分包是利用Socket在TCP协议下内部的优化机制。
1、什么是粘包
只有TCP有粘包现象，UDP永远不会粘包，为何，且听我娓娓道来。发送数据时间间隔很短，数据了很小，也就是发送数据比较频繁，会合到一起，产生粘包；
2、什么是分包
当我们发送的数据量很大的时候，可能是几千字节，TCP就会自动分开发送，其实说通俗点，就是你去拿快递，一看20个，一次拿不完，分几次拿！
3、总结
指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。出现粘包现象的原因是多方面的，它既可能由发送方造成，也可能由接收方造成。
发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。
若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。
这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。分包是指在出现粘包的时候我们的接收方要进行分包处理。
在前面的测试程序中，是没有粘包问题的，这时候你可能有疑惑，我为啥数据会发送的特别快，我们以游戏服务器举例，比如游戏有联机对战功能，这时候肯定是需要同步位置信息的，这个频率是很快的，大约每秒就要40~80次，这个时候就会出现粘包问题。
其实很简单只要简单修改一下客户端即可。
1、程序测试 — 粘包问题
客户端：
服务器查看调试信息：
服务器已启动......
有一个客户端进行连接成功......
从客户端接收到的数据：0
从客户端接收到的数据：123
从客户端接收到的数据：4567
从客户端接收到的数据：8910
从客户端接收到的数据：1112131415
从客户端接收到的数据：161718
从客户端接收到的数据：192021222324
从客户端接收到的数据：25262728
从客户端接收到的数据：2930313233
从客户端接收到的数据：34353637
从客户端接收到的数据：38394041
从客户端接收到的数据：42434445
从客户端接收到的数据：46474849
从客户端接收到的数据：50515253
从客户端接收到的数据：5455565758
从客户端接收到的数据：59606162636465666768
从客户端接收到的数据：6970717273
从客户端接收到的数据：74757677
从客户端接收到的数据：78798081
从客户端接收到的数据：82838485
从客户端接收到的数据：86878889
从客户端接收到的数据：90919293
从客户端接收到的数据：9495969798
从客户端接收到的数据：99
（很明显数据没有发送100次）
1、程序测试 — 粘包问题
客户端：
服务器查看调试信息：
服务器已启动......
有一个客户端进行连接成功......
从客户端接收到的数据：
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000撒大声地所多所多所多所多所多所多所多所多所多所000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000撒大声地所多所多所多所多所多所多所多所多所多所多所多所多所多所多撒大声地所 多所多所多所多所多所多所多所多所多所多所多所多所多所多撒大声地所多所多所多所多所多所多所多所多所多所多所多所多所多所多000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000----------------------------------------------------------------撒大声地所多所多所多所多所多所多所多所多所?
从客户端接收到的数据：
77777777777777777777777777777777777777777777777777777777790909090909090909090909090909090909090000000000000000000000000099
（可以看出服务器是分两次接收的，但其实只要static byte[] dataBuffer = new byte[1024]给的空间足够大，分包问题就可解决）
其实也很好解决，我们在发送数据的时候事先存储数据的长度，不过用来存储数据长度的内存大小需要指定好，否则就没法判断了。
假设我们现在的数据出现了粘包，如下图所示：
这里只是演示一下，如果只有连续发送4次数据，一般是不会出现粘包的，看上图橙色部分表示我们用一个int32类型储存数据的长度，蓝色部分为我们实际要发送的数据，现在发生了粘包，也就是这四条数据合在一起发送给了服务器，
此时这条数据的总大小为 4字节 * 4 + 5 + 7 + 10 + 4 = 42字节
我们通过读取4字节数据可以知道数据的实际长度，以第一个数据为例，我们读取4字节数据，知道了这个数据有5个字节，程序如下：
int data_length = BitConverter.ToInt32(_data, 0)
此时的data_length = 5此时我们就读取这5个字节的数据即可！
string s = Encoding.UTF8.GetString(_data, 4, 5)
然后我们截取数据，从源数据的第4 + 5的位置开始截取到一个新数组，新字节数组索引从零开始，此时新字节数据的长度为42 - (5 + 4)；（下图为新字节数组）
Array.Copy(_data, 5 + 4, _data, 0, 42 - (5 + 4))
依次循环下去，粘包就被成功的分包了。当然这个不要忘记每次更新一下当前数据长度。
_curLength = _curLength - (data_length + 4)// _curLength = 42 - (5 + 4)
1、客户端
创建Message类，用于发送数据前做处理，使得首4字节储存数据长度。
Message：
Main：
2、服务端
创建Message类，解决粘包问题！
Main：
服务器查看调试信息：
服务器已启动......
有一个客户端进行连接成功......
解析到一条数据：0米
4
8
解析到一条数据：1米
4
630
解析到一条数据：2米
4
622
解析到一条数据：3米
4
614
解析到一条数据：4米
4
606
解析到一条数据：5米
4
598
解析到一条数据：6米
4
590
解析到一条数据：7米
4
582
解析到一条数据：8米
4
574
解析到一条数据：9米
4
566
解析到一条数据：10米
5
558
..............................................................................
解析到一条数据：98米
5
18
解析到一条数据：99米
5
9
有客户端退出.....
你解决个屁，异步接收的情况下，把_data数组调大点就完了，傻逼，咱们是做游戏！一般不会有分包问题！！
所访问的服务器问题。例如游戏服务器用户负载高、能力不足都有可能造成丢包的，建议更换其他服务器入口测试。
路由器（Router）是连接两个或多个网络的硬件设备，在网络间起网关的作用，是读取每一个数据包中的地址然后决定如何传送的专用智能性的网络设备。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）