前段時間測了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通訊單次的發送、接收應該基本沒有什麼問題了。至於多次交互涉及到的關聯等技巧 ，請參考後續內容。