NOTE: High level support for Terminal Emulation was introduced in Silk Performer 7.3. In order to make use of this support it is recommended that you upgrade . The information below is based on earlier versions of Silk Performer. Telnet traffic is recorded using WebTcpip* functions in Silk Performer. The Telnet server responses will be recorded by the function "WebTcpipRecvExact". The role of this function is to retrieve an exact number of bytes from the server, however this can cause errors during replay if the server response is dynamic in size. For example you might encounter error such as "Web Engine: 13 - The connection closed gentle, but earlier than expected". The problem with the dynamic server responses for Telnet traffic can be rectified by implementing one of three possible solutions: Solution 1) - TcpRuleRecvProto if server using length specification Open the record.log file (which is generated by the Silk Performer Recorder) and check the server responses (TcpipServerToClientBin) to see if the server uses packet length specification in the response data. The packet length specification is normally located in the first few bytes of response data and is in hexadecimal format; for example the Hex representation of 127 bytes is 7F and as you can see below this is specified in the first byte of the response data. TcpipServerToClientBin(#680, 127 bytes) { 00000000 777777777777 7F 0A 0D 0A 0D 0A .... } Once you have verified that the server responses contain a consistent packet length specification you can implement the TCP/IP recording rule called TcpRuleRecvProto which is used for packet length specification. Implementation of this rule will ensure that the dynamic server responses are dealt with during the record process; thus eradicating the need for script customization for successful replay. Solution 2) - TcpRuleRecvUntil if server using terminating sequence Open the record.log file and check the server responses (TcpipServerToClientBin) to see if the server is using a unique terminating sequence at the end of each server response. The terminating sequence will always be the last bytes sent by the server, in the example of a termination sequence below the character H is used to terminate the server response; you can see that the Hex notation of H is 48. TcpipServerToClientBin(#680, 8 bytes) { 00000000 7[11;46H 1B 5B 31 31 3B 34 36 48 } Once you have have verified that the server response contains a termination sequence you can implement the TCP/IP recording rule called TcpRuleRecvUntil. Implementation of this rule will ensure that the dynamic server responses are dealt with during the record process; thus once again eradicating the need for script customization to achieve a successful replay. For further information on how to implement the above approaches you should read the white paper called "Rule-Based Recording", which can be found by going to: START | PROGRAMS | SILKPERFORMER 7.1 | DOCUMENTATION | ADVANCED CONCEPTS Solution 3) - TelnetReceiveResponse If you have ruled out that the server response does not use either packet length specification or a terminating sequence then the final alternative is to replace the failing WebTcpipRecvExact functions with the function "TelnetReceiveResponse" detailed below. This custom function works by accepting incoming server responses of unspecified length in a loop; the loop is then terminated when the client waits for a new response packet for more than a specified number of seconds. There are three input parameters for this function: hWeb0: Is the handle of the open TCP connection fTimeout: Defines how to decide when the server response is complete: If after fTimeout seconds, no further server response is available, the function returns. sAction: This string is used for appropriate naming of the custom timer, and can be used for logging and debugging purposes. The key parameter is "fTimeout" which is the duration the function will wait after the last byte of data is received from the sever before exiting the loop. The Syntax of the function is as follows: function TelnetReceiveResponse(hWeb0: number; fTimeout: float; sAction: string): number var sData string; nRecv: number; nRecvSum: number; fTime: float; begin gsResponse := ""; nRecvSum := 0; MeasureStart(sAction); while WebTcpipSelect(hWeb0, fTimeout) do if NOT WebTcpipRecv(hWeb0, sData, sizeof(sData), nRecv) then exit; end; if nRecv = 0 then exit; end; SetMem(gsResponse, nRecvSum + 1, sData, nRecv); nRecvSum := nRecvSum + nRecv; end; MeasureStop(sAction); MeasureGet(sAction, MEASURE_TIMER_RESPONSETIME, MEASURE_KIND_LAST, fTime); if fTime fTimeout then fTime := fTime - fTimeout; end; MeasureIncFloat("RespTime: " + sAction, fTime, "sec", MEASURE_USAGE_TIMER); TelnetReceiveResponse := nRecvSum; end TelnetReceiveResponse; For further information on how to implement the above approach using the function "TelnetReceiveResponse" you should read the white paper called "Load Testing Legacy and Custom TCP/IP Based Protocols" - "Telnet, TN3270e, and Custom Protocols", which can be found by going to: START | PROGRAMS | SILKPERFORMER 7.1 | DOCUMENTATION | ADVANCED CONCEPTS The two most common questions asked by Silk Performer users are regarding the input parameter "fTimeout": Q) How do I know how which value I should specify in the fTimeout parameter for the function TelnetReceiveResponse? A) The fTimeout input parameter should be the duration in seconds in which you are certain that the complete response will be returned by the server. This value can be gauged by running a series of benchmark tests in Silk Performer; such as a Try-Script and Baseline test before then checking the TrueLog Explorer Info Tab to see how long the WebTcpipRecvExact function call took to execute. Once you have obtained this value you should then consider adding additional seconds on to the value in order to create a buffer to deal with slower server responses for when the server will be under load conditions. Another good way to gauge the value is to run a series of increasing Workload tests to ascertain if the fTimeout specified is long enough. Q) Will adding a high duration of seconds as the fTimeout value/parameter skew the response times of the server during a loadtest? A) No, The fTimeout value will only affect the duration of the loadtest (how long it will actually take the loadtest to execute); it is very important to note that the value has absolutely no affect on the response times captured and reported in Silk Performer. To understand why the fTimeout time has no affect on the response time returned by the server I would recommend that your first take the time to carefully review the code of the function TelnetReceiveResponse which is shown above. Now consider an example of how the function might appear in a BDF script. TelnetReceiveResponse (hWeb,"4.0","Login Successful"); Hypothetically speaking when the above function was executed the first response time returned by the function "MeasureGet(sAction, MEASURE_TIMER_RESPONSETIME, MEASURE_KIND_LAST, fTime);" was 4.7 seconds. We get the value 4.7 seconds because the server took 0.7 seconds to send the complete server response to the client and the timeout period was 4 seconds. The function "TelnetReceiveResponse" is designed to wait until after the last byte has been received (or no further data from the server) before commencing the countdown to the specified timeout period so that it can exit and continue onto the next API call. The reason for the Timeout is used is because often a Telnet server will send a series of characters and then wait a few seconds before sending the rest of the data; therefore the timeout is used as a fail safe mechanism. Normally the timeout would skew your response times by 4 seconds and thus cause inaccurate reporting of results. However the function has an inbuilt loop which is used to remove the timeout period from the response time, like so: if fTime fTimeout then // if 4.7 4.0 fTime := fTime - fTimeout; // 0.7:= 4.7 -4.0 end; Finally now when the function MeasureIncFloat is called within the function "TelnetReceiveResponse" it will correctly record the accurate response time of 0.7 seconds and write it to the Silk Performer Overview Report as a Custom Timer.
↧