I am stuck at very critical junction of my scripting in Jmeter, I have a requirement to upload a file on Azure storage and a Microservice which analyze the blob data to process further but it looks for certain size, example 8081920 bytes. I am successfully able to upload the the file of same size on Azure storage but the service returns size Mismatch.
If I upload the same file using Postman, service is able to process the image successfully. Below is the Postman request Header
x-ms-blob-type: BlockBlob
Content-Type: image/raw
User-Agent: PostmanRuntime/7.26.10
Accept: /
Postman-Token: b9384ac9-7fbe-4ab8-834b-aef0d8114588
Host: xxxxxxx.blob.xxxxxx.windows.net
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 8081920
Jmeter Request Header:
Connection: keep-alive
Content-Type: image/raw
Accept-Encoding: gzip, deflate, br
Accept: /
x-ms-blob-type: BlockBlob
Content-Length: 8082155
Host: xxxxxxx.blob.xxxxxx.windows.net
User-Agent: PostmanRuntime/7.26.10
Any idea how to resolve this from where jmeter sending additional 235 Bytes but Postman doesn't.
Thanks,
Akshat
Content-Length header is being automatically calculated by both tools as:
sum of request headers (bytes) + request body (bytes)
Given you haven't provided the body we cannot state where the inconsistency lives, from what I can see is that Postman sends Postman-Token and JMeter doesn't so JMeter's Content-Length should be less
In case of multipart file upload the discrepancy can be caused by different boundaries but it shouldn't have any impact on the image processing.
In any case given you're able to successfully upload the file using Postman and cannot do this using JMeter - you can just record the request from Postman using JMeter's HTTP(S) Test Script Recorder - this way you will get confidence that requests are exactly the same. Just make sure to copy the file you're uploading to "bin" folder of your JMeter installation, this way JMeter will be able to properly capture the request.
More information: How to Convert Your Postman API Tests to JMeter for Scaling
Related
I have to perform load testing of a particular application and am using JMeter for that.
In my application, I have a unique access token which will be obtained on successful login and this token has to be passed to the consecutive requests to obtain the response.
Now I have added a recorder for my test plan and ran the HTTP test script recorder.all the browser action is recorded in the recorder of the test plan.
the structure of my test plan and workbench is as mentioned below.
**Testplan-**
*Threadgroup*
Recorder-
//inside the recorder
[Request1-login
Request2-To load the uploaded images by the corresponding user]
//Outside the recorder inside the thread group,
View Results Tree
HTTP Cache Manager
HTTP Coockie Manager
**WorkBench**
HTTP(s) Test Script Recorder
By default, there is a header manager for each request when recorded what I did was to add the extracted token obtained using json extracter of the request1 to the header manager of the request2 in the recorded script.
The token is getting passed along with the request header as shown below but the response obtained is unauthorised.
Request Headers:
Connection: keep-alive
Referer: http://localhost/
Accept-Language: en-US,en;q=0.5
Origin: http://localhost
Content-Type: application/json;charset=utf-8
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0
Accept: application/json, text/plain, */*
Authorisation:91kLM68tdMBoDFRURArvdmwYgWV9Nr2sHYDwivTM.91kLM68tdMBoDFRURArvdmwYgWV9Nr2sHYDwivTM.Arvdm_M68-BoDFRURArvdmwYgWV9Nr2sHYDwivTM
Content-Length: 0
Host: http://localhost/phpmyadmin/index.php
I have checked the same token in postman and am obtaining the correct response.
am I missing out something?Is there anything else I have to take care of before running the recorded test script?Please help
Compare exactly (Header + Body) requests :
sent by postman
vs request sent by JMeter
There must be a difference somewhere.
And in CookieManager ensure you have set Policy to "standard" if using JMeter 3.x
As per your comment:
Authorization was misspelled (Authorisation)
I'm using a POST request in jmeter as below,
POST https://aumaz-ap-perf-ess-web-2.aumaz-ase-dev002.p.azurewebsites.net/signalr/connect
POST data:
clientProtocol=1.5&connectionData=%5B%7B%22name%22%3A%22bulkprocesshub%22%7D%5D&connectionToken=DWGWhf7zGj9TyO4cZn2kqH%2Bennba0V7qyAuAE2wIeu3vIoj%2FrLXemcaBz%2Fto3JjEs%2BaVviiFagxtax8E9PbE36cnBAlrByzw5qBwmIu9glop75vPY3XI0me52yTDiWC%2B9Zoalg%3D%3D&processId=b47fe282-8112-4a11-a18c-7629ac31b816&transport=longPolling
Request Headers:
X-Requested-With: XMLHttpRequest
Accept: text/plain, */*; q=0.01
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Referer: https://aumaz-ap-perf-ess-web-2.aumaz-ase-dev002.p.azurewebsites.net/ESS/DataType
Connection: keep-alive
Connection: keep-alive
Host: aumaz-ap-perf-ess-web-2.aumaz-ase-dev002.p.azurewebsites.net
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Length: 315
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
If I use the same POST request in browser i can able to get the exact response. But in jmeter I'm getting the response as Bad request.
As of now, I'm using jmeter 3.01 and I have installed all the certificates needed. Can anyone please give solution for this
The most problem here seems to be that server doesn't respond with any details of what's wrong with the request. Correct?
Then do two things:
1) Install Fiddler, capture what you're sending through browser, and through JMeter, compare.
That may give you a clue what's the difference.
2) Reach server logs and see what's going on, there may be way more intrinsic information on why request was considered invalid.
I have finally got a solution. If I pass those parameters in parameters it doesn't work but i gave all the parameters with & in the path itself.
And used ${__urlencode{parameter}} to encode the parameters which are passing as encoded value and then I didn't face any Bad request issue.
Even now, I don't know how it worked. But finally got a solution by this way.
I have been encountering error in storing a file to Object Storage using HTTP POST method sent using Async XMLHttpRequest. The request is a CORS HTTP request sent to the Object storage public URL with required headers set. The error message says: Reason: CORS header Access-Control-Allow-Origin missing.
The error seems to happen with multipart form data send request using POST. If PUT is used to create the file, the required file (resource) gets created. The response to the PUT request contains the required Access-Control-Allow-Origin header, whereas the response to POST does not contain despite the meta data attributes being set on the container.
I have even tried using X_AUTH_TOKEN header instead of X_STORAGE_TOKEN, but the failure continues to happen.
Raised the ticket with Softlayer support, but have not received a solution. Any ideas to resolve the above would be helpful.
The details are below:
The container prod_file has following meta data attributes set:
access-control-expose-headers: Access-Control-Allow-Origin
access-control-allow-origin : *
The Firefox browser version is: Mozilla Firefox 46.0
Client OS is: Linux 3.16.0-71-generic #91~14.04.1-Ubuntu SMP Mon Apr 18 1K9:43:36 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Request URL: https://*****.objectstorage.softlayer.net/v1/AUTH_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/prod_file/6ffb51fc-e40f-4cf5-982c-44cb5c342851.fl.file.orig.txt
Request HTTP Method: POST
Mechanism used: Async XMLHttpRequest
Request Headers:
Host: *****.objectstorage.softlayer.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Storage-Token: AUTH_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Referer: http://*****myorg******.com/organization/572680760cf26af856c7432c/resources
Content-Length: 4500
Content-Type: multipart/form-data; boundary=---------------------------2139255891192408661525197545
Origin: http://*****myorg******.com
Connection: keep-alive
Response Headers:
Connection: keep-alive
Content-Length: 50
Content-Type: text/plain
Date: Sat, 14 May 2016 14:57:02 GMT
X-Trans-Id: *****Some Transaction Id********
The error response has the following message:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://*****.objectstorage.softlayer.net/v1/AUTH_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/prod_file/6ffb51fc-e40f-4cf5-982c-44cb5c342851.fl.file.orig.txt. (Reason: CORS header 'Access-Control-Allow-Origin' missing)
Thanks for the help in advance.
It looks like you set wrong the headers for your container, please take a look this documentation and try it:
http://docs.openstack.org/developer/swift/cors.html
https://swiftstack.com/blog/2013/04/02/using-cors-with-swift/
Renember that softlayer object storage is based in Open Stack.
Let me know if you are still having troubles
Regards
I have a question for using Apach JMeter.
Our project, Android apps post json data with "Gzip Compression" to API server.
The Android apps using "Apache HttpClient" and it's "GzipCompressingEntity" class.
For performance testing of API server, I tryed to recording the request by JMeter's Proxy (="HTTP(S) Test Script Recorder").
But the recorded request body was empty.
What I want to do is to send "Gziped HTTP request data" from Apache JMeter to server.
Is there any way for that?
Following is sample of our Android app's request header.
POST /api/test HTTP/1.1
Content-Type: application/json
Transfer-Encoding: chunked
Content-Encoding: gzip
Host: 192.168.11.11:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.5)
Accept-Encoding: gzip,deflate
RequestBody is Gziped binary data.
What I had done is
Run the "HTTP(S) Test Script Recorder(Proxy Server)" on JMeter.
Set http proxy of Android to use that proxy server.
Execute Android test code of HTTP Client (the post data is compressed by Gzip).
then, that test code finished with failure. (no response from server)
If access directly (without JMeter's Proxy Server), that test succeeded.
Can I send the compressed request data from JMeter just like this?
Add HTTP Header Manager to your test plan and add at least the following headers:
Content-Type: application/json
Content-Encoding: gzip
Add Beanshell PreProcessor as a child of the request which you need to encode and add the following code to it's "Script" area:
import org.apache.commons.io.IOUtils;
import java.util.zip.GZIPOutputStream;
String bodyString = sampler.getArguments().getArgument(0).getValue();
byte [] requestBody = bodyString.getBytes();
ByteArrayOutputStream out = new ByteArrayOutputStream(requestBody.length);
GZIPOutputStream gzip = new GZIPOutputStream(out);
gzip.write(requestBody);
gzip.close();
sampler.getArguments().getArgument(0).setValue(out.toString(0));
It will get your request body, compress it and substitute on the fly so the request will be gzipped.
Encoding is wrong, you need to save it in body like this
sampler.getArguments().getArgument(0).setValue(new String(compressedBody, 0));
I have a strange problem with JMeter.
I've made recording of some sort of web application without any problems. Problem appears during playback of test.
For some reason I receive different results during playback than during recording.
When I compare Http Request made during recording and playback I don't see a single difference (except for some security token which I'm extracting from earlier requests and passing as parameter).
To be more exact during recording I receive a response with a big body (>5kB), and during playback body of response is empty. Response code is 200 (OK).
This body contains crucial data from database, so I'm afraid that measurement made by this JMeter script will not reflect actual behavior of application, simply I will not measure what I really need.
Now my questions:
is there some tool or JMeter plug-in which will allow more effectively see contents of HTTP requests and its responses? It would be great If I could compare of requests made during recording and playback. So far I used two listeners: "View Results Tree". I've sandwiched between them to compare request from recording and playback.
is there some known bug in JMeter which could explain the difference? For example something related to recording process?
Here is example of request:
POST http://10.133.27.81:8080/c/portal/render_portlet
POST data:
p_l_id=69210&p_p_id=blank_WAR_Blank_INSTANCE_iNM3&p_p_action=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_pos=1&p_p_col_count=2
[no cookies]
Request Headers:
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Accept-Language: pl
Accept: */*
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
csrf_token: 1GXK-0QD7-GFPJ-JLDG-JP2G-J390-BFLG-7LL7
Pragma: no-cache
Method: POST /c/portal/render_portlet HTTP/1.1
X-Requested-With: OWASP CSRFGuard Project
Referer: http://10.133.27.81:8080/group/bou
Accept-Encoding: gzip, deflate
Content-Length: 143
Host: 10.133.27.81:8080
Update: to make sure which headers or parameters are constant I made 4 recordings of same test case during different sessions and compared them, so I'm quite sure that only csrf_token has to be field with value fetched from other request. I've added debug sampler to verify that this value is fetched properly.
Update 2: Problem found.
There where two problems:
There is a bug in JMeter when you do a search (Ctrl-F) it searches the whole project except for HTTP Header Menagers and my request contained csrf_token inside of header (I detected that before posting this question). Making a search in xml using text editor was good workaround for that.
when I try to find source of problems, before I've found problem number one, I've added a new problem by removing a HTTP Cookie Manager (I'm blaming myself and IE for this).
Generally changing Internet Explorer to FireFox with HttpFox add-on help to spot the problem.
Thanks everyone for support.
Marek
Response code 200 doesn't have to mean that everything went well at the application level.
To find out more details you can use Debug sampler and Debug PostProcessor.
Example here.
Your issue comes certainly from a missing dynamic request parameter that you didn't compute.
Look for example at csrf_token header Did you make it variable? Or do you transmit its initial recorded valur, but also at any parameter that contains some hashdata or numeric data referencing some content that does not exist in your page or request.
For example col pos I see p_p_col_id and related parameters, are you sure they reference something in your replay.
There is really very little chance of a JMeter bug in this case.