none
Response time for submitted tasks RRS feed

  • Question

  • Having a problem with HPC SOA. Running on 2008R2 SP4.

    I'm using the following architecture:

    - creating a session and a broker client

    - sending tasks via the broker client without calling EndRequests

    - waiting for responses on a different thread with GetResponses() - continous polling basically

    I don't call EndRequests ...ever.. because I want to keep that session alive for faster responses. 

    The problem I have is that even though the tasks process fairly quickly (50-100ms) ... I'm receiving responses only after 3 seconds from the time I've launched the tasks. I've checked the timestamps.. and the tasks are received straight away, processed straight away...but responses seem to be bundled up every 3 seconds or so.

    Does anyone know if there is a timer somewhere..or some setting to reduce the polling interval for responses?

    -George

    Wednesday, February 4, 2015 10:22 AM

Answers

  • Hi George,

    Yes, what you observed is correct. There is a response windows in GetResponse enumerator which has a timer would wait for 3 seconds for any new responses to come in before flushing the received responses. This behavior is by design to improve the overall response throughput.

    If  the timely retrieval of the responses is required, and especially for getting responses in another thread. I would recommend to use the callback mode with the SetResponseHandler API. There would be no such buffer window and delay. For the sample code please refer to here.

    Cheers,

    Yutong

    • Marked as answer by George Alexe Monday, February 9, 2015 12:07 PM
    Monday, February 9, 2015 2:59 AM
    Moderator

All replies

  • Did you call Flush between each batch of requests? Only after Flush success, the requests are dispatched to calculate.

    For 3 seconds delay, do you mean you get all responses 3 seconds after you flushed? or you received one response each 3 seconds?

    GetResponse shouldn't exit if you don't call EndRequest for your client.

    Thursday, February 5, 2015 9:48 AM
  • Hi George, suppose the result is from an interactive session created by Session class, isn't it? For interactive session, there is no bundle for requests/responses to persist into the MSMQ storage. The 3 second delay for the first response could the round trip cost for the message to go through client, broker and compute node, and plus the message/task processing time.

    Regards,

    Yutong

    Thursday, February 5, 2015 12:50 PM
    Moderator
  • The problem doesn't seem to be with Flush. The tasks get to the engines in due time...around 50ms..or something of the sort.

    I'm getting the responses 3 seconds after submitting the first task. Since they are submitted in rapid succession, the time between the first task and last one can be disregarded (less than 50ms).

    The problem is that instead of receiving a response right after the task finishes, I receive it after around 3 seconds.

    For example :

    T: Send task 1 + task 2 + task 3

    T+50ms: Tasks get to the engines

    T+150ms: All tasks have finished processing

    T+ ~3000ms: First response is received by GetResponse.(the rest follow shortly, a few ms after)

    I am aware that GetResponse will not exit unless I call EndRequest...my application is based on that.

    • Edited by George Alexe Thursday, February 5, 2015 2:04 PM Forgot to mention response behavior
    Thursday, February 5, 2015 1:13 PM
  • Hi Yutong,

    Yes, an interactive session created by the Session class.

    The 3 second delay can't be explained by network lag, because this doesn't happen when submitting the tasks.

    I've added timestamps and checked that the clocks are in synch for the machines and this is what I see:

    T: Sending tasks

    T+50 ms: Tasks arive at the engines

    T+150 ms: Tasks have finished processing

    T+ ~3000ms: I get the first response

    If I can submit tasks and have them asigned to engines in a few milliseconds (I've put there 50ms but it might be even lower) ... my task finishes processing in 100ms(at most) ... I don't see a reason for receiving responses 3 seconds later. 

    Since I am running a continuous session (not calling EndRequests) .. I can repeat this test over and over... resubmitting tasks to the grid, so we can exclude any library loading / network glitch / initial setup  phases. I keep getting the same pattern... 3 second delays between submit and receive.

    Thursday, February 5, 2015 1:26 PM
  • I've uploaded a small test-app that has the same behavior as the one I am seeing.

    https://drive.google.com/file/d/0B5gNLfHyUEdPSzJ6RE5qQWdONXc/view?usp=sharing

    Responses are received 3 seconds after tasks have finished processing...

    Before running, you'll need to set the headnode name and service name in the main program.

    Also, the credentials used are the ones that are already cached.



    • Edited by George Alexe Friday, February 6, 2015 8:48 AM Forgot to mention limitations
    Friday, February 6, 2015 8:38 AM
  • Hi George,

    Yes, what you observed is correct. There is a response windows in GetResponse enumerator which has a timer would wait for 3 seconds for any new responses to come in before flushing the received responses. This behavior is by design to improve the overall response throughput.

    If  the timely retrieval of the responses is required, and especially for getting responses in another thread. I would recommend to use the callback mode with the SetResponseHandler API. There would be no such buffer window and delay. For the sample code please refer to here.

    Cheers,

    Yutong

    • Marked as answer by George Alexe Monday, February 9, 2015 12:07 PM
    Monday, February 9, 2015 2:59 AM
    Moderator
  • Hi Yutong,

    Yes, that did it. Thanks!

    I totally forgot about SetResponseHandler. I was using the GetResponses approach before the BrokerClientBehaviors was implemented since it allowed me to receive responses without blocking the last response when EndRequests was not called.

    So, as a note for whoever runs into this again:

    Use SetReponseHandler for handling responses, but before setting the response handler make sure you have the BrokerClient. Behaviors set to BrokerClientBehaviors.None;

    Setting this property after setting the response handler doesn't work as expected, last response will still be pending until EndRequests is called.

    Best regards,

    -George

    Monday, February 9, 2015 12:04 PM