1. 程式人生 > >loadrunner socket 協議 歸納(一)

loadrunner socket 協議 歸納(一)

      前段時間測了loadrunner直接傳送報文到socket上的效能測試。在此,稍微回顧整理下。

      與socket通訊,有兩種方式,一種是建立長連線,建立後,不停的傳送,接收。另外一種是建立短連線,建立連線,傳送報文,接收響應,關閉連線。兩種方式server的開銷不同。Loadrunner可以把建立連線(關閉連線)是否放在VUSER_INIT(VUSER_END)中設定以上兩種通訊方式。

Step1:建立連線的程式碼如下: int sc=0; sc = lrs_create_socket("socket1","TCP","RemoteHost=131.252.83.233:15017",LrsLastArg);

if (sc == 0)

       lr_output_message("Socket was successfully created ");

else

   lr_output_message("An error occurred while creating the socket, Error Code: %d", sc);

step2:建立連線成功後,就需要往socket上傳送報文,傳送報文的程式碼如下:

 lrs_send("socket1", "buf2", LrsLastArg);

Q1:那麼有人會問這裡的buf2是在哪裡配置的?這個就需要我們開啟指令碼中的data.ws,這部分是放置是socket通訊傳送和接收報文的。上面的傳送報文的語句中buf2就需要在data.ws中配置。

配置例子如下:

send buf2 275 "/x30/x32/x37/x31”

這裡我們分別解釋一下各欄位的含義:

第一個符號“send“是代表buf2是傳送報文。Data.ws中的報文有兩種,一種是傳送buffer,一種是接收buffer,各自對應的符號標記為”send”和”recv”

第二個符號是buffer名稱,

第三個符號”275”是buffer長度,這裡需要說明一下,send型別的buffer,loadrunner是根據下面配置的buffer內容來計算實際buffer長度的,因此對於send型別的buffer,這裡的buffer長度只作為參考,實際上是無意義的。而recv型別的buffer,這裡配置的buffer長度就必須特別注意了,loadrunner會根據配置的長度去接收socket上內容,loadrunner會嘗試去讀取一個符合配置長度的buffer內容。第二行是buffer內容,對於”recv”型別的buffer,loadrunner實際上是隻是在log中會打印出expect receive buffer =你配置的buffer內容。

Q2:這裡有人會再問,類似web(http)協議,傳送的報文需要引數話,怎麼做。Loadrunner裡面操作也很簡單,選中需要引數話的報文內容-》右鍵――》引數化。後期的操作與web協議一樣。

Q3:這裡有人會接著問,buffer裡面配置的內容,以什麼的編碼方式,能夠自行設定嗎?這裡我們可以再看loadrunner的配置,recording options,這裡有一項配置,translation table. LoadRunner編碼方式分為:ASCII碼、EBCDIC碼。如果選擇Translation Tables中“None”方式,就是ASCII編碼;其他都是選擇EBCDIC編碼方式,比如 00250352。其實Server是用0025方式編碼,Client是用0352方式。 LoadRunenr有自己的ebcdic字典,路徑是“/ebcdic”。 EBCDIC碼:8位編碼,可表示256個字元。EBCDIC是Extended Binary Coded Decimal Interchange Code之縮寫,成為擴充套件式2進位制10進數交換碼或稱擴充套件式BCD碼。它是以左邊4個區域位元(Zone bit)及右邊4個數位位元合計8個位元組的資料碼,一共可組合2的8次方=256種組合方式。 Note that the following functions overwrite the same internal buffer (user buffer): o lrs_ascii_to_ebcdic o lrs_ebcdic_to_ascii o lrs_get_received_buffer o lrs_get_static_buffer o lrs_decimal_to_hex_string

Step3:傳送成功後,需要接收報文,一般判斷測試是否通過是根據返回報文中的內容是否符合預期值來確認transaction是否通過。這裡示例程式碼如下:

 lrs_receive("socket1", "buf3", LrsLastArg);

lrs_save_param_ex("socket1", "received", "buf3", 0, 90,"ebcdic", "Response1");

lr_output_message ("消費Response: %s", lr_eval_string(""));

position=(char*) strstr(lr_eval_string(""),

lr_eval_string("0170100400"));

if(position==NULL)

     lr_end_transaction("消費", LR_FAIL);

else

    lr_end_transaction("消費", LR_PASS);

Q4:這裡有人會問,為什麼我的程式碼執行到lrs_receive的時候,log裡面列印Waiting for writable socket 10 secs, 0 usecs,都需要等待10秒鐘。是這樣的,因為你在data.ws中定義了recv buffer的長度,例如你定義為100,但是socket上的返回buffer長度不是100,這時候,loadrunner會嘗試再次去讀取,直到讀到長度為100的buffer才算成功。嘗試多次,超時時間為多少?loadrunner預設為10s,所以你這裡才會有等待10s的情況出現。我們可以指定超時時間:lrs_set_recv_timeout(1,10); 第一個引數是s,第二個引數是ms

當然實際情況,多數socket返回的響應buffer是變長的,這種情況下我們可以採取如下措施:

1.如果知道變長的recv buffer以什麼結尾的話,可以設定loadrunner讀取的時候,讀到什麼內容的時候停止讀取。 lrs_set_receive_option(EndMarker, BinaryStringTerminator, "//x00//x07Mercury"); 具體lrs_set_receive_option還有多種用法,請參加幫助文件 2.或者我們手工指定loadrunner指令碼,捕獲多長的buffer。就需要使用如下程式碼來代替lrs_receive: lrs_receive_ex("socket1", "buf3", "NumberOfBytesToRecv=150", LrsLastArg); 到此為止,socket通訊單次的傳送、接收應該基本沒有什麼問題了。至於多次互動涉及到的關聯等技巧 ,請參考後續內容。