Decompression Errors explained

July 18, 2011 | By kiranbadi1991 | Filed in: Browser, Decompression, LoadRunner, Performance Center, Performance Engineering, Scripting, SilkPerformer.

This in continuation to my earlier post where I had written some of my observation to decompression errors which we see frequently while running the load tests in Performance Center or LoadRunner.These kinds of errors should not be hard  to debug if we know the variables  that comes into the play while replaying.So I will try to explain as why we normally see decompression errors while replaying the scripts in Load Testing tools.

Compressing the data and transmitting it over the wire saves the huge bandwidth and space.This also helps in reducing the overall response time of the page.It is also best practice to compress the data and send it across the wire as by doing this you are sending less amount of data across the wire. gzip/Deflate are the one of the most commonly used schemes to compress and send the data across the wire.Now after the servers has compressed the data and send it across the wire,it’s the job of the client to decompress and render the data to the client.This decompression functionality built in the client is the root cause of the error which we see during the load testing.Depending the type of the library,client load testing tool has implemented ,content of the error message might vary.So for the sake of this post,I will concentrate only on LoadRunner tool.Below are the some of the errors which I have seen with LoadRunner.

  • Z_Data_ERROR(-3)
  • Z_MEM_ERROR(-4)

The error message thrown should be read in the below format,

“Error xxxxx:’Decompression function (wgzMemDecompressBuffer) failed. Return code=’return code’ (‘string’), inSize=’input buffer’, inUse=’input bytes processed’, outUse=’output buffer'” (This I have learned from HP Support site).

LoadRunner tool needs to be told to capture  headers while recording the business flow and this can be done easily by going into the Recording options , Over there we can set up the  appropriate headers that are required to be captured.However I would say that LoadRunner default recording mode as it is works in the most of the cases,however there are some cases where it might not work correctly, and those cases are the ones where we see these kinds of the decompression errors.

Normally the flow of the headers for compressed data looks as below,

1. Client sends the request to the server indicating that it can accept the compressed data and  can decompress it as its end.This expression of interest is send via header to the server.The headers send by the client here looks like below,

Accept-Encoding: gzip,deflate

Please note that whenever we mention both gzip and deflate in the client request,it means that client is able to decompress both gzip and deflate schemes response received from the server.However for load testing purpose ,its not advisable to set the both schemes in your script. One needs to find out exact scheme used by the server and set it accordingly.This information can be found out either while recording the the script with all header enabled in recording options or by using third party tools like fiddler or Live Http headers.

2. Server responds to the client request by sending the compressed data. This compressed data is identified by the client by reading the server headers.The server response headers looks like below,

Content-Encoding: gzip

Content-Length: xxxx bytes

This means that server is using Gzip content encoding scheme and the size of the file the client needs to decompress before rendering the content to the user.

LoadRunner and most load testing tools follow the same steps,they indicate to servers, that they can decompress the request successfully if server is sending the compressed data.If for some reasons, if data is not decompressed by the LoadRunner,depending on the kind of situations ,one might come across either of these 3 types of errors or some extra errors like Z_STREAM_ERROR etc. .

Z_DATA_ERROR: Means that data received by the LoadRunner as the server response for the request cannot be decompressed at the LoadRunner level either due to bad data or data being corrupted in the way or LoadRunner is not aware that it needs to decompress the data.If you are getting very low amount of these kind of error messages, it either means that your load generator is overloaded or you have network issues intermittently which is corrupting the packets or your servers are having some kind of bottlenecks and due to these bottlenecks they are not in position to send the complete file to the client.Normally by looking at the content length received from the server response over the duration of time for the same request,one can make out if the server is having the any kind of bottlenecks.If content length looks similar across many requests and if LoadRunner has successfully decompressed some requests and some have failed, it means that either your LG’s are overloaded or you are having networks issues which corrupts the data flowing across the wire.

Z_MEM_ERROR: This error is received if for some reasons your LG’s boxes are running low on memory requirements,and due to less amount of memory,LoadRunner is not able to decompress the server response.Monitor your Load Generator boxes for memory usage.

Z_BUFFER_ERROR: In case if you have specified the correct headers  with correct schemes (Gzip/Deflate)and have followed my  earlier post on this and still you  see this error, it means that you need open the incident with HP Support.Some where the implementation of zlib Library in LoadRunner is not doing what it is suppose to do.

In case if you are interested in learning more on compression and how they are implemented , I would suggest the following sites ,

My understanding is that most of the tools uses the above techniques and should also be using these libraries for decompressing the servers responses.

Hope this writing helps and shows direction to understand and debug various decompression errors encountered during load testing.

Tags: , , , ,

Comments are closed here.