I'm using a compute with single core cpu as the compute host.
1 My first question is that whether Symphony only trigger one session instance to run (by calling the onInvoke() function) at the same time on such one core cpu environment. And what will Symphony deal with the onInvoke() on multi-core cpus.

2 When I test my programmes, I found that when i send several input requests Symphoyn trigered onInvoke() serveral times, and only called onSessionLeave() a few times.
Also I want to know when will Symphony call onSessionLeave() onServiceDestroy() and onInvoke(). Does each input request trigers all these functions?

3 When a compute node handle two sessions and both sessions has a few input requests
(1)Symphony serve all the requests of one session first and then serve the requests of the other session
(2)Symphony serve the requests according to their arrival order.
Which way above is the Symphony working in?

Thanks for your rapid reply to my last post.
Sincerely.

I'm using Symphony version 3.1.

Thank you again.

1. In Symphony, one SI (Service Instance) is run on a slot. You can configure the EGO part of Symphony (DE works differently) to have more than one slot per host. I believe there is also a way to tell EGO to configure one slot per CPU. You should check your Symphony documentation to learn how to do this.

When Symphony (SSM) wants to start a service instance, it gets a slot from EGO and then starts a SIM on that host. The SIM in turn starts an SI process.

2. OnSessionEnter and OnSessionLeave are triggered in pairs. OnSessionEnter creates a session with some common data. OnInvoke is then called many times - depending on the number of tasks in the session. OnSessionLeave is then called when there are no more tasks for the SI. If the SSM decides to shutdown the SI due to having no work for it, OnSessionDestroy is called. In 3.1, OnSessionDestroy may not be always called, as the shutdown process may timeout causing the process to be killed. In general, you can count on OnSessionLeave always being called for each session.

3. Depends on the number of slots. If you have one host with one slot, then option (2) best describes the behaviour. Tasks for one session are serviced by an SI. When there is no more work, OnSessionLeave (session 1) , OnSessionEnter(session 2) is called and the tasks for session 2 are sent to the SI.

If you have more than one slot, the slots are divided evenly between sessions - if possible - and workload completes in parallel.

- Ajith

I did not understand your answer to my question 3 quit well.
Does Symphony
1 handles one session firstly and the other sessions will block for the running session
2 serves the requests according to their arrival order.

arrival order:
input 1 (SI1) | input 2 (SI1) | input 1 (SI2) | input 2 (SI2) | input 3 (SI1)

serve order (one slot) :

option 1

input 1 (SI1)
input 2 (SI1)
input 3 (SI1)
input 1 (SI2)
input 2 (SI2)



option 2
input 1 (SI1)
input 2 (SI1)
input 1 (SI2)
input 2 (SI2)
input 3 (SI1)


Thanks.



The net connection is slow. Sorry.

Hi Simon,

The SSM sends input tasks to the SIM one task at a time. The arrival order is only important if the input tasks arrive at the SSM more slowly than the SIM and SI can process them. Assuming the above scenario, option 2 is correct - but will never happen. Option 1 is most likely to happen.

In most cases, all the input tasks arrive at the SSM before any SI's have processed tasks. The SSM assumes that session switching is expensive, so it will process all the tasks it has for the first session before switching to the second one. This will potentially starve out the second session if the first session has a constant stream of workload.

There's one exception, if the input tasks for session 1 arrive in two groups and the SSM has no session 1 tasks to process at a given time, it will switch to processing input tasks for session 2. As soon as new input tasks arrive for session 1, the SSM will switch back to processing tasks for session 1.

This assumes that the session priorities are the same. The first session to arrive at the SSM always has priority.

The workaround is to never give an application's consumer just one slot. Even if you have a single cpu compute host, give it at least one slot for each session that you expect to run in parallel.

- Ajith