I am new on here and new to J-Meter so bear with me.
I am trying to add items to a table on sql from a .csv file (Columns in .csv file are 'id', 'text', 'userId'). 200000000021,01232456459,john.smith#example.com. id and userId are same values. Text increments + 1 each time. About 40 records in the file.
I am using a Bearer token as Authorization, but each time I am running the test (json parameterized request) , I am noticing in the Results Tree Viewer I am getting a 200 but several 500 responses, then another 200 etc
Why won't all my requests appear as 200? Do I need to add a delay between each request?
Results Tree Viewer
I would ideally need this running over 3 threads
Thread Group properties
Any pointers would be greatly appreciated.
Thanks
Expecting to see 200 responses against all requests processed
HTTP Status 500 means Internal Server Error
The HyperText Transfer Protocol (HTTP) 500 Internal Server Error server error response code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.
This error response is a generic "catch-all" response. Usually, this indicates the server cannot find a better 5xx error code to response. Sometimes, server administrators log error responses like the 500 status code with more details about the request to prevent the error from happening again in the future.
So first of all check "Response Data" tab of the s listener for any suspicious entries, it might be the case the server tells you what went wrong.
If there is nothing useful there - check your server and/or database logs, it might be the case you will be able to figure out the reason from there
Then you could try running your test several more times to see if the behaviour is repeatable, i.e. whether the same requests with the same data failing all the time
It might be connected with concurrency, i.e. only one request is allowed at the moment, try decreasing the number of concurrent users to 1 and see whether it resolves your issue
Check Sharing Mode setting of the CSV Data Set Config, if it's different from the default value of All threads it might be the case 2 users are sending the same request and your server and/or database doesn't allow duplicate values.
Related
I have recorded a script from login till the opening of Oracle form.
Then i split the program into two parts, one with login and other as Navigation to form and open.
Login is successfully executing but the navigation script is giving me an error HTTP-error code 500
T03_Amar_Navigation.c(95): Error -26612: HTTP Status-Code=500 (Internal Server Error) for the URL [MsgId: MERR-26612].
there is no problem while logging in and opening oracle form manually.
can someone help me what I may be missing?
I tried copying all the correlation parameters into the navigation as well, no error or mismatch with correlation parameters
Best guess, based upon seeing this 500 condition hundreds of times in my career, is that you need to check your script for the following
Explicit checking for success on each step, or expected results. This is more than just accepting an HTTP 200. This involves actually processing the content that is returned and objectively looking at the page for elements you expect to be present. If they are not present then you will want to branch your code and elegantly exit your iteration. A majority of 500 level events are simply the result of poor testing practices and not checking for expected results.
Very carefully examine your code for unhandled dynamic elements. These could be related to session, state, time or a variable related to user/business process. A mishandled or unhandled dynamic element cascading for just a few pages results in an an application where the data being submitted does match the actual state of the business process. As this condition is something that would not be possible with the actual website, you wind up with an unaddressed exception in the code and a 500 pushed back to the user. There are roughly half a dozen methods for examining your requests for dynamic elements. I find the most powerful to be the oldest, simply record the application twice for the same data, then compare the scripts. Once you have addressed the items related to session, state and time, then record with a different data set (user, account, etc...) and look at the dynamic elements related to your actual data in use.
Address the two items above and your 500 will quite likely go away.
I'm building a web-based reporting tool that queries but does not change large amounts of data.
In order to verify the reporting query, I am using a form for input validation.
I know the following about HTTP GET:
It should be used for idempotent requests
Repeated requests may be cached by the browser
What about the following situations?
The data being reported changes every minute and must not be cached?
The query string is very large and greater than the 2000 character URL limit?
I know I can easily just use POST and "break the rules", but are there definitive situations in which POST is recommended for idempotent requests?
Also, I'm submitting the form via AJAX and the framework is Python/Django, but I don't think that should change anything.
I think that using POST for this sort situation is acceptable. Citing the HTTP 1.1 RFC
The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that
describes the result.
In your case a "search result" resource is created on the server which adheres to the HTTP POST request specification. You can either opt to return the result resource as the response or as a separate URI to the just created resource and may be deleted as the result resource is no longer necessary after one minute's time(i.e as you said data changes every one minute).
The data being reported changes every minute
Every time you make a request, it is going to create a new resource based on your above statement.
Additionally you can return 201 status and a URL to retrieve the search result resource but I m not sure if you want this sort of behavior but I just provided as a side note.
Second part of your first question says results must not be cached. Well this is something you configure on the server to return necessary HTTP headers to force intermediary proxies and clients to not cache the result, for example, with If-Modified-Since, Cache-control etc.
Your second question is already answered as you have to use POST request instead of GET request due to the URL character limit.
Consider a service running on a server for a customer c1,but customer c1 times out after 'S' sec for what so ever be the reason so customer again fires the same request ,so server is running duplicate query hence it gets overloaded, resolve this glitch. Please help me !!!
I assume you are on the server side and hence cannot control multiple requests coming in from the same client.
Every client should be having an IP address associated with them. In your load balancer(if you have one) or in your server you need to keep an in-memory cache which keeps track of all requests, their IP addresses, timestamp when request originated and timestamp when request processing finished. Next you define and appropriate time measure - which should be near about 70-80% percentile of processing time for all your requests. Lets say X seconds.
Now, before you accept any request at your loadbalancer/ server you need to check in this in-memory cache whether the same IP has sent the same request and the time elapsed since the last request is less than X. If so do not accept this request and instead send a custom error stating something like "previous request still under processing. Please try after some time".
In case IP address is not enough for identifying a client, as the same client may be sending requests to different endpoints on your server for different services, then you need to store another identifier which maybe a kind of token/session identifier - such as c1 or customer id in your case. Ideally, a customer can send only 1 request from 1 IP Address to an endpoint at any 1 point of time. Just in case you have mobile and web interfaces then you can add the channel-type(web/mobile/tablet) as well to the list of identifying parameters .
So now, a combination of - customer id(c1), IP address, request URL,request time, channel-type will always be unique for a request coming in. Using a key of all these parameters in your cache to uniquely fetch information for a request and validating whether to start processing the request or send a custom error message to prevent overloading the server with re-requests - should solve the problem defined above.
Note - 'S' seconds i.e. client-side timeout - given that the client-side timeout is not in our control - should not concern the server-side and will have no bearing on the design I have detailed above.
I want to correlate this 181-418-5889 in the following statement: regSend&transferNumber=181-418-5889".
I used the regular web_reg_save_param: But it failed... any suggestion?
You are using the statement in the wrong location, such as using it just before the request is sent containing the correlated value versus just before the location where the response containing the value is sent to the client
You are not receiving the correct page response and as a result you may not be able to collect the value. The page may be an HTTP 200 page but the content could be completely off. Always check for an appropriate expected result
Your left boundary, right boundary and other parameters are incorrect to collect the value you need
You have not been through training and you are being forced by your management to learn this tool via trial and error
1- I am not using the statement in the wrong location since I did find the needed value I want to correlate via the Tree function and put it just before the statement that hold this value
2- The Page is not an HTTP 200
3- The Left and right boundary are correct since I checked the text if it does exist twice in the response body.
4- I know the tool (Loadrunner) but in fact, the application is developed under ZK platform and I am not sure if ZK and Loadrunner are compatible knowing that I did implement the dtid function in my script to have a static desktop id each time I replay the process.
I have two phones connected to a Wifi access point, both have ip in the private range.
One of the phones has a HTTP server running on it and the other phone acts like a client. The client sends GET requests data to the server as name/
value pairs in the URL query string. At the moment the server is only sending on HTTP.OK on receiving the query string.
What is happening is the client may not be stationary and maybe moving around so it may not be possible for it to be in range always of the Wifi access
point due to that I am not getting all the data sent from the client at the server end.
I want to ensure that all data sent is actually received by the server.
What kind of error correction should I implement? Can I check for some relevant HTTP error codes or the like?
If the HTTP server doesn't receive the entire query string in a GET request, then the HTTP request cannot possibly be valid as these parameters are on the first line of the request.
The server will be unable to handle the request and in this case will likely return status code 400 (Bad Request).
If your client receives this (which seems unlikely that it would fail to transmit the request, yet receive the response), then you'll know to retransmit. In general, the properties of TCP connections like automatic retransmissions, checksums and timeouts should be all you need for successful delivery, or to determine failure.
You need to check for timeouts on the client. That depends on the process/language used.
EDIT: http://wiki.forum.nokia.com/index.php/Using_Http_and_Https_in_Java_ME
Looks like you simply set a timeout and catch IO errors.
Premature optimization.
Connection integrity is already dealt with in the lower parts of the network stack. So if there were any dropouts in the middle of the request (assuming it spanned more than a single packet) the TCP stack would attempt to recover them before passing the data on to the server.
If you need to prove this to yourself, then just add a checksum as the last part of the query.
C.