4

I have a similar problem as Criteria for selecting timeout value?. But my question is slight different.

Process A dependes on process B and has a timeout value of 5 seconds, sometimes process B might take longer to respond(e.g. slow machines), in this case process A will think process B is gone and will terminate.

We have a performance requirement, so the goal is to always respond on the least feasible time. This application runs on tablets, notebooks, desktops and even servers. In a scenario were the host machine performance can vary widely, how can we adjust the timeout taking into account machine performance?

  • If 5 seconds timeout is too short for some cases, and assuming A resumes as soon as B is done or killed, why not simply take a longer timeout ? – Arthur Havlicek Sep 18 '15 at 17:44
  • A longer timeout would work with tablets, but would be crazy long when running on a last gen i7. – Tulio F. Sep 18 '15 at 17:53
  • 5
    The purpose of a timeout is to identify a problem like a stalled process. Wouldn't that purpose be served even if the timeout is longer than you would expect from a faster machine? If your purpose is to identify things that take too long, then log performance measurements instead. – Robert Harvey Sep 18 '15 at 17:54
4

I see two different options, use the one that makes more sense for the details of your use case:

Option 1: Immediately return from callback with longer timeout

It doesn't matter if the timeout is longer on a faster system, if it can immediately return and break you out of the wait period once the process is complete. So while the timeout is "10 seconds", on a fast system it could be effectively "1 second" or even faster.

Option 2: Don't give up on the first try

You can wait the 5 seconds, if there's no response, try again. Perhaps take three tries before giving up and terminating. You can modify the user interface to say something like "connecting to process B attempt #1, connecting to process B attempt #2", etc. so that it doesn't seem too long to the user, so that it looks like something is happening.

  • Option 2 works best for us, we already had something similar but wasn't sure about it, thanks. – Tulio F. Sep 21 '15 at 14:10
0

It sounds like you have more of a performance scaling problem rather than a classic 'stop waiting if it takes too long' scenario

eg, say my app notifies me when a goal is scored in a football match. Every X seconds it polls a server to see if a goal has been scored.

If the server is down or slow I can switch to a backup server, so I don't want to wait forever. But the backup is slower than the main server. so I don't want to switch unnecessary. Also I want to know about the goal as soon as possible after it happens.

If I poll every second, the sever will be overloaded and start responding slowly, delaying the news. but if I only poll every minute the server may be capable of responding much quicker.

Here a simple static timeout of X seconds is unhelpful. if its too short I will switch the the backup too often. If its too long, I will wait too long before switching. My app needs a dynamic shifting expectation value for how long it expects the server to take.

To get this I need to log how long each request takes and modify the apps behaviour according. ie switch to the backup, make more or fewer requests or in your case terminate process A

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.