对流媒体服务器达尔文进行性能测试的总结(winsock)(转)

对流媒体服务器达尔文进行性能测试的总结(winsock)
刚刚搞了公司流媒体服务器达尔文的性能测试工作，有点进展。把自己的一点收获总结一下跟大家分享一下。

      loadrunner没有直接支持达尔文的协议，所以选择winsock协议进行脚本录制。

   大致的脚本如下：

#include “lrs.h”

Action()

{  int a=1;

lrs_create_socket(”socket0″, “TCP”, “LocalHost=0″, “RemoteHost=192.168.0.7:554″,  LrsLastArg);

lrs_send(”socket0″, “buf0″, LrsLastArg);

lrs_receive(”socket0″, “buf1″, LrsLastArg);

lrs_send(”socket0″, “buf2″, LrsLastArg);

lrs_receive(”socket0″, “buf3″, LrsLastArg);

lrs_send(”socket0″, “buf4″, LrsLastArg);

lrs_receive(”socket0″, “buf5″, LrsLastArg);

lrs_save_param(”socket0″,NULL,”newsession”,178,19);

lr_output_message(”session is:%s”,lr_eval_string(”“));

lrs_send(”socket0″, “buf6″, LrsLastArg);

while (a=1)

        {

                }

/* lrs_receive(”socket0″, “buf7″, LrsLastArg);

lrs_create_socket(”socket1″, “UDP”, “LocalHost=6972″,  LrsLastArg);

lrs_create_socket(”socket2″, “UDP”, “LocalHost=6973″,  LrsLastArg);

lrs_receive(”socket1″, “buf8″, LrsLastArg);

lrs_send(”socket2″, “buf9″, “TargetSocket=192.168.0.7:6971″, LrsLastArg);

lrs_receive(”socket2″, “buf10″, LrsLastArg);

……

    lrs_close_socket(”socket2″);

lrs_close_socket(”socket1″);*/

lrs_disable_socket(”socket0″, DISABLE_SEND);

lrs_close_socket(”socket0″);

return 0;

}

其中     lrs_save_param(”socket0″,NULL,”newsession”,178,19);用来关联buf5中服务器传来的session id。buf5如下：

recv  buf5 486

        “RTSP/1.0 200 OK\r\n”

        “Server: DSS/5.5 (Build/489.7; Platform/Linux; Release/Darwin; \r\n”

        “Cseq: 2\r\n”

        “Last-Modified: Thu, 22 Dec 2005 01:59:56 GMT\r\n”

        “Cache-Control: must-revalidate\r\n”

        “Session: 2347936984390074812\r\n”

        “Date: Thu, 22 Dec 2005 12:27:08 GMT\r\n”

        “Expires: Thu, 22 Dec 2005 12:27:08 GMT\r\n”

        “Transport: RTP/AVP;unicast;source=192.168.0.7;client_port=6972-6973;server”

        “_port=6970-6971;ssrc=401DA4CB\r\n”

        “x-Transport-Options: late-tolerance=0.400000\r\n”

        “x-Retransmit: our-retransmit\r\n”

        “x-Dynamic-Rate: 1;rtt=68\r\n”

        “\r\n”

其中session id 由第178位开始连续19位，将其保存在中。用它替换之后由客户端发起的rtsp请求中的session id

如buf6：

send  buf6 268

        “PLAY rtsp://192.168.0.7:554/sugar.3gp RTSP/1.0\r\n”

        “CSeq: 3\r\n”

        “Range: npt=0.000000-134.200000\r\n”

        “x-prebuffer: maxtime=2.000000\r\n”

        “x-transport-options: late-tolerance=10\r\n”

        “Session: \r\n”

        “User-Agent: QuickTime/7.0.3 (qtver=7.0.3;os=Windows NT 5.1Service Pack 2)\r”

        “\n”

        “\r\n”

脚本中的while（a=1）{}只是用来让程续停留在那里，不往下执行用的。用来举个例子，没什么意义，意思就是当rtsp连接建立完成，服务器开始通过rtp协议向客户端发送流之后永远不关闭rtsp连接。大可加入有意义的控制。

      此脚本中注释掉了录制到的RTP连接的建立，因为个人认为加入那个对控制流的发送没意义，做起来又容易出错。

     在自己家，CONTROLER里面试一下，就用3个用户。打开ethereal，运行场景。截获的包中前后显示客户端发起3次describe、setup、play，服务器的应答都是成功，各自有不同的session-id。之后是服务器发来RTP包，传输开始了。我想这样基本就成功了吧。

      明天开始测了，不知道还会碰到什么问题。有了我在补上。

经过两天测试,碰到一个问题:连接不能长时间保持.我想这个问题应该是因为服务器长时间没有收到客户端的响应发生的.于是将脚本中的

while (a=1)

        {

                }

更改成

while (a=1)

{

                     lr_think_time(60);

        lrs_send(”socket1″, “buf8″, LrsLastArg);

        }

buf8如下：

send buf8 252

        “PLAY rtsp://192.168.0.7/sugar.3gp RTSP/1.0\r\n”

        “CSeq: \r\n”

        “Range: npt=0.000000-134.200000\r\n”

        “x-prebuffer: maxtime=2.000000\r\n”

        “x-transport-options: late-tolerance=10\r\n”

        “Session: \r\n”

        “User-Agent: QuickTime/7.0.2 (qtver=7.0.2;os=Windows NT 5.0Service Pack 4)\r”

        “\n”

        “\r\n”

作用就是连续向服务器发送rtsp的play请求.

流媒体服务器会根据其中的CSeq依次处理请求，所以我将后面的值做了参数化。应为公司极其上没有安装VC等可以制作DLL的工具，暂时不使用user defined fountion的参数化方法，不然的话那倒是最好的方法。在这里，我使用的是file的方法（准备一个4到2000dat文件，每行一个数字）这个办法也足够脚本运行个进30个小时了。

其中的”Session: \r\n”是上面做的关联。

脚本中的   lr_think_time(60);在本次测试中有意义，他保证了4到2000的Cseq能用上几十个小时。

测试到今天，我最大的体会是

“对业务过程的理解（在本次测试中体现为对rtsp协议的了解）对性能测试实在是太重要了”