Looking at https://jmeter-plugins.org/wiki/GraphsGeneratorListener/ plugin it mentions server "hits". Is that when JMeter wrote HTTP request to the Java socket, or does that include the server's reply? What about network errors, like the request has been sent, but no reply received within the sampler's request timeout, or there was an established connection error, or connection failed to establish - is that still a hit?
From source code, it looks like Server Hits per Second checks sample start time:
private void addHits(SampleResult res) {
// ...
addHit("Server Hits per Second", normalizeTime(res.getStartTime()), 1);
Unless I missed something, it's seems unaware of the protocols at all: it will build the graph based on start time of all samplers/sub-samplers included in Graphs Generator configuration, regardless of their type. That includes filter on their status (failed or success).
So answers to your questions depend on Graphs Generator configuration: you can include and exclude failed results, which will define whether timed out or connection error samplers will be included or excluded. To achieve "JMeter wrote HTTP request to the Java socket" you need to make sure only HTTP requests are included. To only include requests which received some response, you need to exclude failed requests.
Related
I am using a plugin (WebSocket Samplers by Peter Doornbosch) to establish the WebSocket connection in JMeter and trying to send the request message over it but receiving below error in logs
ERROR - eu.luminis.jmeter.wssampler.RequestResponseWebSocketSampler: Unexpected frame type received in sampler 'WebSocket request-response Sampler': Close frame with status code null and close reason 'null'
My test plan consists of "WebSocket Open Connection", "Web-socket request-response sampler" and "web-socket ping/pong frame filter". And I feel there is no issue in establishing the connection but something is wrong while sending the request or receiving a response.
Also, tried checking the logs from the server but didn't find any requests which were sent using JMeter.
Implemented another available plugin too in Jmeter to test the WebSocket but seeing similar behavior. Any help would be highly appreciated.
It looks like you're using the wrong sampler type, looking into the error you're getting it makes more sense to use single-write sampler which is designed for sending one (text or binary) WebSocket frame.
You might want to use a sniffer tool like Fiddler or Wireshark to capture the traffic between your browser (or application) and the backend and see what types of frames are going, which direction, is single connection re-used or each time new one is established, etc.
You may also find the following links useful:
Example scripts collection
JMeter WebSocket Samplers - A Practical Guide
The problem is that your server is actively closing the connection. Usually, this is caused by the client sending a request that the server does not understand. In your case, it's very likely that the request you are sending in the request-response sampler is not accepted by the server. As Dmitri suggests, the best way to find out how a "normal" client communicates with the server is to capture a session with WireShark and model your testplan accordingly.
Hth.
I am requesting for an endpoint which actually creates a task so when I am trying to execute my jmeter script with 500 threads then I am facing some issue. For first 200 threads I am getting 200 response and after that I am getting 400 Bad Request error with the same end point.
Please help me out in this.
Thanks.
Could you check the status of your web server?
There are possibility that web server's connection pool is full.
As per HTTP Status Code 400 documentation
The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
So I would recommend:
Double checking your request details (url, parameters, etc.) using i.e. View Results Tree listener
Check jmeter.log file for any suspicious entries
Review your test configuration, for instance if you use CSV Data Set Config which is set not to recycle at the end of file you will be sending <EOF> instead of real values which will not be accepted by the server
Make sure to follow JMeter Best Practices as it might be the case JMeter cannot conduct more than 200 virtual users load due to lack of resources
I have an unknown App consuming my Spring webservices.
The app set a timeout to every webservice calls.
The server regardless of the app timeout keeps processing.
Is there a risk of any other webservice call in receiving a misresponse (the response to the timed out webservice call)? How does Spring manages this? Doesn't HTTP protocol take care of this, given that each connection channel is open for a particular call to webservice and if broken there shouldn't be possible to retrieve the response?
As a developer, you should try to make all possible HTTP requests to your web server to be idempotent. It means that the client side has to be able to retry the failed request without new possible errors due to the inability to know the previous (timeout) request results.
The client side should handle the HTTP client timeouts himself and (by default) should treat the timeout error as a failure. Your clientside may repeat the request later and the server side should be able to handle the same request.
The solutions may vary for different tasks depending on complexity (from an INSERT statement to the database or scheduling a new CRON job avoiding duplication).
I found golang context is useful for canceling the processing of the server during a client-server request scope.
I can use http.Request.WithContext method to issue the http request with context, but if the client side is NOT using golang, is it possible to achieve that?
Thanks
I'm not 100% sure what you are asking, but using a context for sometime like a timeout is possible for both handling incoming requests and outbound requests.
For incoming requests you can use the context and send back a timeout http status code indicating that the server want able to process the request. It doesn't matter what the client sends you, you get to decide the timeout on your own with the server.
For outgoing requests you don't need the server to even know you have a timeout. You simply set a timeout and have your request just cancel if it doesn't get a response back in a set time. This means you likely won't get any response from the server because your code would cancel the outgoing request.
Now are you asking for an example of how to code on of these? Or just if both are possible?
I am writing a REST service where the result of a REST POST can take longer than the environments timeout settings for HTTP connections. Given that I can't change the timeout for my REST target url,
What can I do to to make a REST call pass properly? I thought about using an async controller, but that seems not to fix any timeout behavior.
The calling client should not have to handle any server error or try to re-execute the query, as it is just adding more stress to the server.
Cheers,
Kai
Assuming this is a connection read timeout and not a http keepalive timeout since there is only one query. One suggestion would be for the rest service to return intermittent status response every specified interval. If this is a tcp keepalive issue then it can be circumvented using configuration. If a socket read timeout is being set then thst can be increased as well.