I have a Jmeter script where during replay, Post request is displaying as Get request and the parameters in the request are not sent to the server. Due to this, correlations are failing at this request.
One of the parameters in the request is ViewState with so many characters. Is this large parameter value causing the above issue? How to proceed now?
Most probably you're sending a malformed request therefore instead of properly responding to a POST request you're being redirected somewhere (most probably to Login page)
Use View Results Tree listener in HTML or Browser mode to see what page you're hitting in the reality
With regards to the ViewState, "so many characters" is not a problem, the problem is that these are not random characters. ViewState is being used for client-side state management and if you fail to provide the proper value you won't be able to move further so you need to design your test as follows:
Open first page
Extract ViewState using a suitable Post-Processor
Open second page
here you need to pass viewstate from the step 1 along with other parameters
More information: ASP.NET Login Testing with JMeter
Also don't forget to add HTTP Cookie Manager to your Test Plan
What I'm able to understand is the request may be getting redirected. This happens usually when the server expects a unique request. If you recorded the request, you may be possibly using older headers that carry old cookie information. Check your headers and then reconstruct the request.
Make sure you are not using old cookies anywhere. remove that cookie part from HTTP Header Manager everywhere.
Related
I've been trying to use Gatling to load-test our Orbeon servers. More specifically we want to know how many concurrent users the server can handle submitting forms.
I've already captured the requests using Gatling (one request per form field that is filled in). However, the requests are not working when I replay them. My first thought upon inspecting the requests is that it should contain a valid UUID. But where can I generate this ID, or parse it from the initial request? Is it even possible to manually generate these requests?
Any other suggestion for a load-testing tool for Orbeon would also be helpful.
We often do something similar here, using JMeter, but the idea is the same whatever tool you're using. Indeed, Ajax requests:
Need to have to be "in" the same session used to generate the page to which they are related, i.e. typically carry the correct JESSSIONID cookie.
Need to refer to the proper UUID. You can find the UUID in the HTML of the page, in the <input type="hidden" name="$uuid" value="…">.
Need to have the correct <xxf:sequence>1</xxf:sequence> number. I.e. 1 for the first request made after the page is loaded, then 2, and so on.
Using Jmeter GUI, I recorded a test scenario (placing an order) and the script ran successfully. But when I replay the test scripts it doesn't function as it was recorded to do, it did not make an order.
After query the dev, found that with each item selected, the server generate a CSRF token, and put the token in the URL path (Like: /cart/add/type/product_id/7245985/_csrf_token/b46c0aec2e5891808ec42141b1956943204ae8f8) when the item is added to the shopping cart. This is all recorded in the script. This path with the token is used to add the item to cart.
My question is how to test this dynamic token when it is concatenated in the path of URL?
Any help are appreciated.
If you have not already added Tree View Listener to your Test Plan, then add it now. You can use it to view the details of requests & responses. JMeter considers a request successful if it gets "some" response from Server-side. It does not matter if the response is functionally valid or not. So, in order to make sure that JMeter is sending valid parameters and receiving expected response, you will have to check the details of requests / responses in Tree view listener.
You can also add Response Assertions to requests so JMeter itself verifies that it is getting expected responses.
Important Tips:
Use TreeView Listener for debugging only. In real load test keep it disabled as it consumes lot of memory.
Do not use response assertions excessively as they consume lot of memory as well.
JMeter is not a browser-based tool. It just deals with back-end requests. Hence it is expected to be very fast. So nothing wrong with that. You should remove un-necessary timers as there is nothing wrong with it being fast.
If your requests involve some kind of login authorization then have a look at this question for further details Load testing using jmeter with basic authentication
Recording doesn't guarantee working script, it gives you only a "skeleton" and usually you need to perform some correlation (the process of extracting mandatory dynamic parameter from previous response and adding it to the next request).
Reference material:
Building a Web Test Plan
Building an Advanced Web Test Plan
How to use JMeter for Login Authentication?
How to make JMeter behave more like a real browser
My client redirects to a https://domain.com/Controller/GetInfo?Querystring method. Now my query string is getting dangerously close to the 2K limit, so I need to reproduce this behavior but pack my query string into the content of the messages. Since it would be heresy (etc.) to try a GET with content, I'll use a POST. However, I can't redirect to a POST since a Redirect has no content.
So, what I am looking for is the best MVC 5 pattern to resolve this: I need to provide lots of content, but I want the resulting page hosted on my remote server (i.e. as if I had redirected)
Also, since I use load balanced servers in azure, I'd prefer maintaining my clean stateless server if at all possible (else I'll have to introduce session caching).
#AntP is absolutely right in the comments above. If your query string is approaching 2K, then you're abusing it.
If there's a particular object you're referencing, then you can simply include the id or some other identifying piece of it and use that to look it up again from your data store.
If there's no persistent record of the object, then you can use something like Session or TempData to store it between one request and the next.
Regardless, it's not possible to redirect with a request body, with also means it's not possible to redirect using POST. The reason for this that the a redirect is not something the server does, but rather the client. The server merely suggests that the client go to a different URL. It's then up to the client (web browser) to issue a new request for that URL. Since the client is the one issuing the request, it makes the decision about what data is or isn't included in that request, not the server.
I got an eccentric problem. I am trying to automate visiting a web site by using WebRequest and WebClient. I have observed all the post request header key-value pairs and posted data string in Firebug(request Header and Post tab). Then I simulated such request with WebRequest and put all the header parameter and posted data there. However when I do GetResponse() from this request instance, I always got an error page back that says some sessionID is short of.
Actually I have taken care to put previously(first step to open the Logon page) responded session cookie in the Header's cookie field for the request. And I can get the correct response back by simulating requesting the logon page(the 1st page), but cannot get through this authentication page. My post data is like userid=John&password=123456789&domain=highmark.And the authentication page request that carried out by browser succeeds every time.
Am I missing something in the request that may not be shown by firebug.If yes, can you give me some recommendation for the tools that may examine the entire request sent by browser.
I have solved this issue. The problem is I set the httpWebRequest instance's AllowAutoRedirect=true. Thus the effect is when I got the first response from the server, the httpWebRequest would continually to make another request asking for a different url that is replied in the response header's Location field.
The defect of HttpWebRequest class is when it is getting redirected, it does not include the Set-Cookies(Response's Header Field)'s cookies in the next request header, thus the server would deny such page request and may redirect again to another different page.
And the httpWebRequest.GetResponse() method only return the last responsed page back under the setting AllowAutoRedirect=true. And I got the totally different response than I expected.
Also in this solving process, I need to thank to a distinguish Http Traffic examining tool:IEInspector Http Analyzer(http://www.ieinspector.com/httpanalyzer/). The great feature of this tool is it can examine not only the http traffic from browser but also what your process's httpWebRequest made. And also it can display in text format the raw stream of those request and response. Although it is a commercial software, you can try it for 15 days. I am quite happy with what it tells me(in well-formed details) and I like to buy it as well.
I have been told that a POST in some way does a double send to the server but GET does not. It sounds a bit crazy to me though.
Basically I'm working on a web project where each client calls a web service every 2 seconds from many countries and possible bad internet connections. So we want to make the calls and responses as tiny as possible between JavaScript and ASP.Net.
Security is not a problem and basically the poll is just returning data. Login is required to use it anyway.
I have been told that a POST in some way does a double send to the server but GET dose not. It sounds a bit crazy to me though.
You have been told wrong. The only difference is that POST allows for sending larger amount of data to the server and of course the more data you send the slower it will be. But if you send the same amount of data there won't be any difference in terms of performance between a GET and POST request.
One important thing to note as well is that if you are calling this service from javascript GET requests might be cached by the client browser. So for example if you are calling the same url over and over again using an AJAX GET request you might get cached values and the server never hit. To workaround this issue you could append a random number in the query string which has no meaning for the server but which changes the url and avoids it being cached.
When sending thru ajax post, some developers may have inited post on form submit and a submit button click. Later when they press the send button, both actions get fired. This might be the experience that people who have told you double sending thing experienced.
Note: This double sending of POST is totally a developer's fault. HTTP POST method has nothing to do with it.