Tag Archives: loadrunner

LoadRunner error — memory violation: exception access_ Solution

Recently, I was doing the performance test of file download. I used LoadRunner tool to report “error: C interpreter run time error: action. C (1613): error – memory violation: exception access” after running for several times_ VIOLATION received.”。 After careful review of the script and scenario analysis, it is found that: in the fopen method of the script, the file operation mode is “W +”, and Encyclopedia:
W + reads and writes in plain text mode, while WB + reads and writes in binary mode.
W + open the read-write file. If the file exists, the length of the file will be zero, that is, the content of the file will disappear. If the file does not exist, the file is created.
Open or create a new binary file in WB write only mode, and only write data is allowed.
WB + read/write mode opens or creates a binary file that allows reading and writing.
The image file I downloaded belongs to binary file,
all the files that must be read and written with WB +, namely fopen (file, “WB +”);
test again, and the error will no longer appear.
Note: if you are using plain text files, you can use w +, if you are downloading binary files, you must use WB mode.

Error code:10053

Symptoms:
Action.c(16): Error : socket0 – Software caused connection abort. Error code : 10053.

 

normal C/S communication process is :
Server Listen–>

Server Listen–> Client Connect–> Server Accept –> Client Send –> Server Recv–> Client Close –> Server Close
if you do not take the initiative to Close the connection and direct to withdraw from the Client end, Server end service thread will cause a 10053 error (this kind of error usually effect is not too big), and if in the process of the communication Server first initiative to Close the connection, the Client end can also cause a 10053 error

the situation of the bad network is usually refers to the latter, the Client thought the Server off (the actual network broken), so I cried. “10053

Recently, when I used LoadRunner to conduct the performance test of Winsock protocol, the WebServer tested was JBoss, and 10053 errors often occurred. The phenomenon was as follows: after I created the connection with lrs_create_socket, when the number of requests for this socket connection reached 100, the connection was not available, and it had to be closed before creating again. LoadRunner causes Connection abort. Error code: 10053. LoadRunner causes Connection abort.
After much exploration, it was finally found that the error was due to the configuration of the HTTP 1.1 KeepAlive parameter in Apach HTTPServer. From my test results of several different Webservers, it can be seen that JBoss and Tomcat made errors when a Socket connection made 100 requests, while other Web servers, such as IIS and WebLogic, did not have this problem.
several related parameters are described below: KeepAlive, KeepAliveTimeout, and MaxKeepAliveRequests.
KeepAlive Directive
Description: Enables HTTP persistent connections
Syntax: KeepAlive On|Off
Default: KeepAlive On
Context: server config, virtual host
Status: The Core
Module: the Core
In HTTP 1.0, a connection can only transfer one HTTP request, while the KeepAlive parameter is used to support the one connection, multiple transfers feature of HTTP 1.1, so that multiple HTTP requests can be passed in one connection. Although only newer browsers support this feature, this option is enabled anyway.
The keep-alive extension to HTTP/1.0 and The Persistent Connection feature of HTTP/1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over The same TCP Connection.In some The Keep Alive Extension to HTTP/1.0 and The Persistent Connection feature of 1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over The same TCP Connection.In some cases this has been shown to result in an almost 50% speedup in latency times for HTML documents with many images. To enable Keep-Alive connections, set KeepAlive On.
For HTTP/1.0 clients, keep-alive Connections will only be used if they are specifically required by a client. In addition, A keep-alive connection with an HTTP/1.0 client can only be used when the length of the content is known in advance. This implies that dynamic content such as CGI output, SSI Pages, And server-generated Directory listings will generally not use keep-alive Connections to HTTP/1.0 clients.for HTTP/1.1 clients, persistent connections are the default unless otherwise specified. If the client requests it, chunked encoding will be used in order to send content of unknown length over persistent connections.
— — — — — — — — — — — — — — — — — — — — — —
KeepAliveTimeout Directive
Description: Amount of time the server will wait for subsequent requests on a persistent connection
Syntax: KeepAliveTimeout
Default: KeepAliveTimeout 15
Context: server config, virtual host
Status: Core
Module: Core
KeepAliveTimeout tests the time between multiple request transfers in a single connection. If the server has completed one request but has not received the next request from the client, the server disconnects after the interval exceeds the value set by this parameter.
The number of seconds Apache will wait for a subsequent request before closing the connection. Once a request has been received, the timeout value specified by the Timeout directive applies.
Setting KeepAliveTimeout to a high value may cause performance problems in heavily loaded servers. The higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.
— — — — — — — — — — — — — — — — — — — — — —
MaxKeepAliveRequests Directive
Description: Number of requests allowed on a persistent connection
Syntax: MaxKeepAliveRequests Number
Default: MaxKeepAliveRequests 100
Context: Virtual host
Status: Core
Module: Core
MaxKeepAliveRequests is the maximum number of HTTP requests that can be made with a single connection. Setting its value to 0 will support an unlimited number of transfer requests within a single connection. In fact, no client requests too many pages in a single connection, and usually the connection is completed before this limit is reached.
The MaxKeepAliveRequests directive limits the number of requests allowed per connection when KeepAlive is on. If it is set to 0, unlimited requests will be allowed. We recommend that this setting be kept to a high value for maximum server performance.
For example:MaxKeepAliveRequests 500
Finally, although this problem was caused by the parameter configuration of HTTPServer, only LoadRunner would have had this problem, and if Rational Robot had implemented the same functionality, it would not have had this problem, presumably due to the testing tool’s implementation strategy for Socket connections.