socket总结和感觉

基于SOCKET协议的压力测试（一）

前段时间完成了一个在线客服系统的压力测试。被测系统前端页面是通过网页访问的，想当然就用HTTP协议进行录制，但发现录制的脚本里有些操作没有内容。用HTTPWATCH跟踪，看到的结果和LR一致，例如点击排队和与客服对话，客户端与服务端均没有交互。咨询了开发人员，才知道这个对话过程是使用了SOCKET协议做的异步长连接。

使用HTTP+SOCKET的多协议方式进行录制，果然完成了整个脚本的录制。现就整个测试过程中使用的技术细节进行总结。

1.对SOCKET
脚本进行参数化。

SOCKET脚本的通讯参数都保存在DATA.WS这个文件中，被测系统中每个登陆的客户都有一个CUSTID，实测系统与用户间是否超时就是通过这个CUSTID来判断，因为被测系统要求不同用户CUSTID必须是不同的，而录制的脚本中CUSTID都是一致的，因此有必要对CUSTID进行参数化。在DATA.WS中找到SEND中的CUSTID，取最右侧8位数进行参数化，方法是按右键，选择用参数更换，参数类型选择随机数，范围是1到99999999，更新方式选择EACH ITERATION。为了保证CUSTID不重复，在随机数的参数右侧再取了三位数字进行参数化，参数类型选择VUSER ID。对DATA.WS中所有SEND报文里的CUSTID进行参数化。

2.对服务端返回的SESSIONID进行手动关联。

由于SOCKET脚本中存在的SESSIOID无法进行自动关联，因为选择手动关联。关联很好理解，服务端与客户端进行通讯时，可能会向客户端发送一个SESSIONID，以保证唯一性，客户端收到SESSIONID后，向发送报文都需要加到这个SESSIONID才能保证信息是合法的。那么我们把第一次从服务端接收到的SESSIONID保存到一个参数里，这个保存的过程就叫关联，下次客户端向服务端发信息里把SESSIONID的内容进行参数化，参数就选择刚才保存的关联参数,这样就可以解决SESSIONID动态变化的问题。
lrs_save_param_ex("socket1","received","",0,lrs_get_last_received_buffer_size("socket1"),"ascii","session");

DATA.WS报文里在使用SESSIONID的地方使用{session}

3.对服务端返回报文设置检查点的问题。

由于SOCKET协议的系统无法设置文本检查点，只能通过对返回报文进行判断来确定事务是否正确。另外由于服务端返回的报文长度有可能不一致，因此对服务端返回报文最好使用lrs_save_searched_string("socket1",NULL,"rev1","LB/BIN=type\\\":","RB/BIN=,",1,0,-1);

需要注意的是对左右边界的标志字符需要进行转义，例如DATA.WS里出现了一个\，那么我们必需把它转义成\\\，函数才能正确识别。取到验证报文后，对它进行判断，被给出出错信息。

if (strcmp(lr_eval_string("{rev1}"),"1003")!=0 && strcmp(lr_eval_string("{rev1}"),"10015")!=0 ) {
// && strcmp(lr_eval_string("{rev1}"),"1003")!=0

lr_error_message("error:%s_%i",lr_eval_string("{rev1}"),lrs_get_last_received_buffer_size("socket1"));

}

4.指定接收服务端报文的长度。其实对LR而言，服务端返回的报文主要用于验证检查点。经常会出现服务端报文长度不等的问题，如果接收报文长度不相等，LR会等10秒后再接收一次，这样会导致事务莫名奇妙的等待。因此我们可以根据经验指定接收报文长度，避免超时重读的问题。
lrs_receive_ex("socket1", "buf3", "NumberOfBytesToRecv=78", LrsLastArg);

基于SOCKET协议的压力测试（二）

1.上次连接漏掉了一个细节，就是超时时间，否则很多超时过短而造成的检查点失败，其实上事务是成功的。我们可以把超时时间设置成比开发多5到10秒，这样有助于更加真实的反应事务的正确性。

lrs_set_receive_timeout(40,0);

2.以前一直不知道那里可以看到压力场景的详细日志，原来是这个目录里，C:\lr\esb\157\res\log

3.压力测试初期，对各单一场景进行压力测试，经常会出现压不了几分钟被测系统就挂掉的情况，系统很不稳定。开发人员对程序进行修改，解决了程序的BUG，优化了内部流程，大幅度减少控制环节通讯的操作，效果还是很明显，单一场景可以完成30分钟的压力测试。结论是没有经过压力测试的被测系统在测试初期，莫名奇妙的问题，大部分是开发人员的程序BUG导致。

4.压力测试后期主要做混合场景的疲劳测试，单一场景没问题的交易疲劳测试过程中，问题就出来了。出现的问题是，一个小时左右的压力后，系统突然不能接受前台响应，且CPU压力突然升高，20分钟后，系统又恢复服务。LR场景在停止服务前，出现有大量报错，显示接收不到返回报文，无法通过检查点。通过netstat –n的命令查看到很多连接处于CLOSE_WAIT状态。研究压力脚本发现，脚本在结束事务时会向服务器发送结束断开报文后，主动断开SOCKET连接。服务器可能存在堵塞，没有收到脚本发出的断开连接报文，导致大量CLOSE_WAIT状态存在。在网上查询发现大量CLOSE_WAIT连接很可能是UNIX连接数太小导致，因此对服务器的连接数进行调整，由默认的128调整为1024,1024 >/proc/sys/net/core/net。结论时压力测试后期系统的性能问题很多都可以通过调整系统参数解决。

5.本人对系统和数据库的知识不是很多，对于系统监控，个人关注比较多的CPU，内存，IO，网络的变化，看响应时间及TPS与上述资源是否有关联关系。然后JVM内存，系统的连接数也是关注的重点。

6.对于压力测试的目标我有一个想法，在没有明确客户需求的前提下，可以从技术角度做比较纯朴的压力测试，保证系统的稳定性，将系统资源的占用尽可能调整到CPU上，让CPU成为最后的瓶颈。提供系统最佳的并发数，及最大可承受并发数。