My application environment is Tomcat 7.0, JDK 1.7. I am using Jersey for the REST API. One of our post type REST API request takes the processing more than 3 minutes, and it is just approx time, it can be more than 3 minutes. Then we send the response back to the client when our request processing is completed. but here request processing take 3 minutes so I got the request time out at the client side , and I do not get any response from the server , as I expected to success response
Request processing at server is like below:
Start the request
Insert details to db table [this process taking time in seconds]
Copying files to remote computer server [this process taking 3 minutes]
Update/active the files [this process taking time in seconds]
Send response to the client
End the request processing
All the above process must be in transaction , so we can not remove any of the above process,
We had already improve the best performance for Step 2 of the process , and it only happens, when we request with the more than 1 gb size file.
As of now for the temporary solution we had increase the timeout value which is configured in the Apache server.
Now I am looking for the solution of my issue, with any of the following approach:
Suggest me any development or implementation strategies which can resolve the my issue and it should be expected as described me?
How do I tackle the request time out issue?
Looking for the solution which notify the client from the server side , when the response is done?
Looking for the solution which can not close the connection between client and the server with the Jersey REST API implementation?
Thanks & regards
Yatin Baraiya
as i have think to solve the my issue with the following approach.
Process implementation step to resolve the my issue
1.At First Sending request to the server ==========> Server immediately send the response to the client with generating some Id and start the long running process by other thread in the same process.
2.At the client side first it receive the first request response and wait for some seconds and then again send other request to the server for the long running process checking status====> Server get the second request and response to the client regarding the the status of the long running response status with sending in-progress or done
3.If client get the response :in-progress
4.Then client wait for some seconds and again send the request for status check ===> server Sending response to done
5.If client get the response :Done
then it start to take the other request from its queue . [ it will start the process for the next request if and only if client get the done status and generated ID]
it means here we manage the transaction from the client side with sending the multiple request to server and confirm the process is completed successfully or not , then we start to process next action.
With the above approach we got the transaction process ,Let me know is it my approach to solve the said issue , is it enough or any changes is required in this solution?
Related
One of my application sends API url to be hit via SSE.We want to replicate this end to end behaviour.
How to hit a API request whenever we receive a message on SSE connection using Gatling/jmeter.
Usually server sends a message every 4-5 mins in real time.
I'm doing load testing using JMeter for my gaming application.
First I log in my application by HTTP request and then enter into the game(it is a WebSocket connection).
I successfully hit Websocket and able to send the request and receive a response.
Iam using WebSocket Samplers by Peter Doornbosch.WebSocket request-response Sampler captures one response at a time.
But in my application for a single request five JSON response is returned by the server. I need to capture those five responses. so I used WebSocket read sampler.
If I hit that WebSocket by increasing thread count most of the test cases are failed because of timer issue.
Jmeter sends the next request without waiting for previous reponse.
In my application, if one game ends, then the response is sent by the server. After receiving that only next game request must hit.
But the next game request hit the server before the current game ends. can please help me to sort this issue????
Put your WebSocket read sampler under the While Controller and specify the condition for exiting the while loop (it might be something coming from the JSON Extractor)
Jmeter sends the next request without waiting for previous reponse.
this statement is not true, each thread (virtual user) waits for the current sampler to finish before starting the next sampler
What can be the reasons that cause a socket.io session to be crashed and server returns invalid session or session is disconnected ?
There is a specific situation that causes these problems with the session. When a client fails to send the pings at the expected interval the server declares the client gone and deletes the session. If a client that falls into this situation later tries to send a ping or another request using the now invalidated session id it will receive one of these errors.
Another possible problem with the same outcome is when the client does send the pings at the correct intervals, but the server is blocked or too busy to process these pings in time.
So to summarize, if you think your clients are well behaved, I would look at potential blocking tasks in your server.
Ok, I'll illustrate my problem in this figure project's architecture .
In fact, I have a websocket between the react app and the rasa ( tool for creating chatbots) based on flask. bot response need to access to an external API to retrieve some data. Here where things go wrong. Sometimes, these requests take too long to return a response, and that's when websocket misbehave.
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).