I've set up a websockets server using the Alchemy library for stress testing a websockets client. This implements a fire-hose scenario to simulate an existing system where the server sends messages, but the client does NOT... ever.
Everything is working quite well short of one issue... extending the timeout.
I need to let the server run for days; 7, 14 or even 30. The sample code shows how to set hours, minutes and seconds:
TimeOut = new TimeSpan(hh,mm,ss)
I'd like an infinite timeout if possible, or at least be able to run it for up to 30 days.
I've looked thru the docs, and it doesn't address the issue.
Thanks.
According this doc http://alchemywebsockets.net/docs/class_alchemy_1_1_web_socket_server.html#a4c54ee41aa902b35f0b340adbf85c5ec
timeout happends when socket doesn't receive anything for time more than timeout value.
Maximum allowed value for timeout is TimeSpan.FromMilliseconds(Int32.MaxValue-1) that is about 24 days.
If you want to be sure that timout did not happen you can implement own ping-pong methods.
Related
JMeter When the test is scheduled one of the Http request timeout happens exactly after 15 Min.
Even though tried after increasing the timeout to 30 Min in the Http Request Default header > Advance tab, In the Http requests and in the jmeter.properties file(httpclient timeout) still it is not helping gets timeout for the particular http request after 15 Min exactly, Currently tried on both Jmeter 4.0 and 5.0 as well, Need to know why its not considering the custom timeout specified.
By default JMeter HTTP Request sampler doesn't have any timeouts so it will wait forever.
So if you remove all the timeouts - you will disable them completely. The side effect is that if your application will never respond - your test will never end.
Assuming above information my expectation is that there is a 15 minutes timeout somewhere on the server side, check your system under test configuration and any middleware (reverse proxies, load balancers, etc.)
Response time over 15 minutes is very suspicious itself, maybe the nature of application is quite exotic, however I can hardly imagine a user having to wait for 15+ minutes before the next action. I would suggest using profiling and/or APM tools integration with your load test, this way you will be able to get full picture of what's going on during your testing on the server side. If you don't have any monitoring tools in place you can consider using JMeter PerfMon Plugin
I'm creating a chatbot with dialogflow and I have a webhook hosted on heroku (so that I can use python scripts). The webhook works fine most of the time. However when I haven't used it in a while it will always fail on the first use with a request timeout. Has anyone else come across this issue? Is there a way to wake up the webserver before running the script I have written?
Heroku's free dynos will sleep after 30 minutes of inactivity.
Preventing them from sleeping is easy. You need to use any of their paid plans.
See https://www.heroku.com/pricing
Once you use a Hobby dyno, your app will never sleep anymore and you shouldn't be getting request timeouts.
Alternatively, you can also benchmark what's taking a long time to boot your app. With a faster boot time, the first request would be slow but wouldn't get a timeout.
Heroku times out requests after 30 seconds.
I have a .NET 3.5 BasicHttpBinding no security WCF service hosted on IIS 6.0.
I have service throttling bumped up as per MS recommendations.
My service operation is getting called a few hundreds of time conccurrently, and at some point the client gets a timeout exception (59:00, that's whats set in the server and client timeouts).
If I raise the timeout it just hits the new limit.
It seems like the application just "freezes" somewhere and we have not been able to figure out how this happens.
WCF tracing on the server side doesn't come up with anything.
Any ideas regarding what could be the issue?
Thanks
I assume your WebService is not using the new async/await especially wrt the database calls. In that case its because you are blocking your limited threads.
In more detail. IIS/ASP.net only creates a limited number of threads to handle requests. The first...say 8 requests spin up threads and start working. At some point they will hit the database (I am assuming a traditional n-tier app). Those threads sleep. The next say...992 requests hit IIS and are held in a queue.
At some point the database calls return, process stuff...send data to the client. Another 8 requests are dequeued...hit the database...etc...
However each set of 8 requests takes a finite time to complete. With over 900 requests ahead of them, the last 100 or so threads will take at the very least 100 * latency * number of roundtrips before they can start up. If your latency * number of roundtrips is high...your last request will take a long time before it even gets dequeued, hence the timeout.
Two remedies exists. The first, create more threads....will use up all your memory and your IIS crashes. The second is to use .net 4.5 and async/await.
See here for more information
We would like to check every 3 seconds if there are any updates in our database, using jquery $.ajax. Technology is clear but are there any reasons why not to fire so many ajax calls? (browser, cache, performance, etc.). The web application is running for round about 10 hrs per day on every client.
We are using Firefox.
Ajax calls has implications not on client side(Browser,...) but on the server side. For example, every ajax call is a hit on server. ie. more bandwidth consumption, no of server request hit increases which in turn increases server load etc etc. Ajax call is actually meant to increase client friendliness at the cost of Server side implications.
Regards,
Ravi
You should think carefully before implementing infinite repeating AJAX calls with an arbitrary delay between them. How did you come up with 3 seconds? If you're going to be polling your server in this way, you need to reduce the frequency of requests to as low a number as possible. Here are some things to think about:
Is the data you're fetching really going to change that often?
Can your server handle a request every 3 seconds, how long does the operation take for a single request?
Could you increase the delay after inactivity or guess based on previous server responses how long the next delay should be?
Can you stop the polling completely when the window loses focus, and restart it when it's in the foreground again.
If a user opens the same page in a website 10 times, your server should recognise this and throttle its responses, either using a cookie with a unique value in it (recommended) or based on the client IP address.
Above all, instead of polling, consider using HTML 5 web sockets to "push" data to the client - most modern browsers support this. Several frameworks are available that will fall back to polling if web sockets are not available - one excellent .NET example is SignalR.
I've seen a lot of application making request each 5sec or so, for instance a remote control (web player) or a chat. So that should not be a problem for the browser to do so.
What would be a good practice is to wait an answer before making a new request, that means not firing the requests with a setInterval for instance.
(In the case the user lose its connection that would prevent opening too much connections).
Also verifying that all the calculations associated with an answer are done when receiving the next answer.
And if you have access to that in the server side, configure you server to set http headers Connection: Keep-Alive, so you won't add to much TCP overhead to each of your requests. That could speed up small requests a lot.
The last point I see is of course verifying that you server is able to answer that much request.
You are looking for any changes after each 3sec , In this way the traffic would be increased as you fetching data after short duration and continuously . It may also continuous increase the memory usage on browser side . As you need to check any update done in the database , you can go for any other alternatives like Sheepjax , Comet or SignalR . (SignalR generally broadcast the data to all users and comet needs license ) . Hope this may help you .
I am writing an on line chat room based on AJAX/COMET. My design is:
Request
----------------- wait -------------------------> send dump data
----------------- wait -------------------------> send dump data
----------------- wait -------------------------> send dump data
----------------- wait -------------------------> send dump data
----------------- wait -------------------------> send dump data
------ something happened, get response.
Another request
.....
....
As you see, the server hold the request and wait something happened, if there is some event happened, just push data and finish request. Then the client will issuse another request.
There is tick in request, so if there is event happened betweenhe t gap of two requests, server knows that there is pending event for the client.
Before the browser timeout, the server also send some idle data to prevent client from timeout.
Now, here comes the problem: what are timeout behavior of different browsers? I know that browser sends request and wait for data, if it take too long time to wait, it will timeout. But what are those timeout behavior of different browsers? And are there any header that can control the timeout behavior of browser? By knowing the timeout behavior of browsers, so that I can decide how to deal with them. Where can I find those data?
Actually, since the client could be going through proxies, the explicit values of the timeouts for different browsers don't mean as much as you'd think.
Rather, I'd ask why you're asking - you're going to have to deal with timeouts, and no amount of streaming to the browser is going to prevent it every time. So it'd be best to simply requery the server from the client when the connection drops - which is one reason why a lot of people recommend long polling which is what you seem to be trying to do. Regardless of whether you choose a streaming solution or a long poll, you have to allow for connection resets.
For a simple hidden iframe client setup, it's not too hard to do - and it's equally easy for XHR requests, depending on what client side framework you're using.
The timeout for most modern browsers seems to be rather large in IE (60 minutes? Wow), and shorter in FF (about:config says 300 seconds - eek) - but as I said, that doesn't help you against a proxy, where the timeout could be as short as 2 minutes or less, depending on how the proxy admin configured it.
So, in summary - timeouts happen. You can't stop them. Code your client to reconnect when they happen (with a limit to prevent a spin on server down), and don't worry about it further. Besides being more robust, it'll probably also make your code more performant, since you won't be periodically pumping useless data to every client.