the web service request for one of our java rest service gets submitted again from the client/browser after ever 5 minutes in case when the service is taking longer to execute.
Can we restrict this to get resubmitted once it has taken sufficiently longer.
Regards,
Vaibhav
Exactly happened to me, only difference is mine is simple HTTP Post request and not web-service request.
Which application server you are using? Its upto application server to resubmit the request in case of Request Timeout.
You observed it right, the interval of double trigger is exact 5 minutes, that means your HTTP server is configured to timeout after 5 minutes, You need to set the timeout to -1 (infinite) or some sensible longer value so that the request won't get timed out and re-submit again.
Related
How do I interpret Postman response time "Transfer Start"? Apparently it's the time when the first byte of response is received.
I monitored the server log. Seems as soon as I fire off the request from Postman, the server responded. Does it mean I can conclude the slowness is coming from:
Possibility 1: Server slow to response to "Hello" call. (But by watching the log I think I can safely say it isn't the cause)
Possibility 2: Server responded right away, but that small response took a long time to round trip back (AWS transfer speed is asymmetric I think I remember outbound traffic is slow even Postman/My laptop and the VM resides in same region?)
Thanks
My moodle site is hosted on AWS Server of 8 GB RAM, i carried out various tests on the server using JMeter (NFT), I have tested from 15 to almost 1000 users, however I am still not getting any error(less than 0.3%). I am using the scripts provided by moodle itself. What could be the issue? Is there any issue with the script? I have attached a screenshot with this which shows the reports of 1000 users test for referenceenter image description here
If you're happy with the amount of errors and response times (maximum response time is more than 1 hour which is kind of too much for me) you can stop here and report the results.
However I doubt that a real user will be happy to wait 1 hour to see the login page so I would rather define some realistic pass/fail criteria, for example would expect the response time to be not more than 5 seconds. In this case you will have > 60% of failures if this is what you're trying to achieve.
You can consider using the following test elements
Set reasonable response timeouts using HTTP Request Defaults:
so if any request will last longer than 5 seconds it will be terminated as failed
Or use Duration Assertion
in this case JMeter will wait for the response and mark it as failed if the response time exceeds the defined duration
Since Api Gateway time limit is 10 seconds to execute any request I'm trying to deal with timeout errors, but a haven't found a way to catch and respond a custom message.
Context of the problem: I have a function that takes less than 2 seconds to execute, but when the function performs a cold start sometimes it takes more than 10 seconds creating a connection with DynamoDB in Java. I've already optimize my function using threads but I still cannot keep between the 10-seconds limit for the initial call.
I need to find a way to deliver a response model like this:
{
"error": "timeout"
}
To find a solution I created a function in Lambda that intentionally responds something after 10 seconds of execution. Doing the integration with Api Gateway I'm getting this response:
Request: /example/lazy
Status:
Latency: ms
Response Body
{
"logref": "********-****-****-****-1d49e75b73de",
"message": "Timeout waiting for endpoint response"
}
In documentation I found that you can catch this errors using HTTP status regex in Integration Response. But I haven't find a way to do so, and it seems that nobody on the Internet is having my same problem, as I haven't find this specific message in any forum.
I have tried with these regex:
.*"message".*
Timeout.*
.*"status":400.*
.*"status":404.*
.*"status":504.*
.*"status":500.*
Anybody knows witch regex I should use to capture this "message": "Timeout... ?
You are using Test Invoke feature from console which has a timeout limit of 10 seconds. But, the deployed API's timeout is 30 seconds as mentioned here. So, that should be good enough to handle Lambda cold start case. Please deploy and then test using the api link. If that times out because your endpoint takes more than 30 seconds, the response would be:
{"message": "Endpoint request timed out"}
To clarify, you can configure your method response based on the HTTP status code of integration response. But in case of timeout, there is no integration response. So, you cannot use that feature to configure the method response during timeout.
You can improve the cold start time by allocating more memory to your Lambda function. With the default 512MB, I am seeing cold start times of 8-9 seconds for functions written in Java. This improves to 2-3 seconds with 1536MB of memory.
Amazon says that it is the CPU allocation that is really important, but there is not way to directly increase it. CPU allocation increases proportionately to memory.
And if you want close to zero cold start times, keeping the function warm is the way to go, as described here.
I've just deployed a simple Java/Tomcat based application into Elastic Beanstalk (using the java8/tomcat8 config). Mostly the application works fine.
However, all HEAD requests seem to take 60 seconds. Feels like a timeout of some kind. I can't seem to find any settings regarding filtering or delaying particular types of requests. These requests work fine when I run locally. GET requests to the same URL work fine.
I've confirmed that both the Tomcat and the Apache instance on the server log the HEAD request instantly (which indicates they are done with it, right?).
I've confirmed (using telnet) that the client is not receiving any response header bytes until very late. This isn't a problem of the client waiting for a payload or something like that.
Furthermore, the delay is clearly tied to the load balancer's "Idle Timeout" setting. If I push that down to 5 seconds, then the HEAD requests take about 5 seconds, if I set the idle-timeout to 20 seconds then the HEAD requests take just about 20 seconds (always a few ms over). The default is 60s.
What could be causing all HEAD requests (even those returning a 401 unauthorized error, no processing) to clog up the works like that?
Turns out the problem was a firewall issue at the local site. AWS ElasticBeanstock was returning the responses in a timely manner, but they were getting clogged up in a local firewall. Grr..
While testing a webservice we set a connection delay on the server of 5 seconds. Thus you would expect JMeter to give response times >5000ms. In some cases / clients this works fine. As expected, but in others it doesn't.
On some clients JMeter just gives a response time of (e.g.) 315ms, whilst other machines give 5315ms (which includes the 5 second delay). On the problem-machines I also test through SoapUI, same response time, and Firefox. Firefox shows a response time of >5000ms.
Theoretically there shouldn't be a difference between the machines, but obviously there is. I just can't find what.
Please use transaction controller.
All your HTTP/s requests should be part of the same transaction controller.
In order to include the delay time, kindly check/select the property of transaction controller mentioned below:
"Include duration of timer and pre-post processors in generated sample"
hope this will help.