How does Synergy back-end processing affect server performance?

robyu's picture
robyu asked on February 23, 2011 - 8:38am | Replies (5).

Hi Synergy experts...

I need help into understanding Synergy backend session. Doing a ccm monitor or ccm ps command provides me with details of how many process am i running on my Synergy Server.

What i wanted to learn is how this number affects my Unix box performance. We have had issues that there is a dramatic degrade in server performance due to too many running synergy process running.

I have created a little script to check there Synergy connection against my Oracle database. What I do is to kill INACTIVE process traced from oracle and map to unix process ids.

Anyone who have more knowledge how the proper process termination criteria should be?

5 Answers

David Honey's picture

You need to be careful not to kill back end sessions that are running, especially if they are in the middle of a database transaction. This can lead to referential integrity issues in the database that are likely to be reported as errors when you next run [i]ccmdb check[/i].

Are you using web mode?
If not, why not?

In web mode, the Synergy server has a pool of back end sessions that are not specific to users or client sessions. They are used to serve api requests from all clients. In traditional mode (soon to be retired), you have a dedicated UI+ENG pair for each user's client session. In other words, if you have 20 users each running 2 clients, that's 40 back end sessions. This is the advantage of web mode.

David.

robyu's picture
robyu replied on February 24, 2011 - 6:37am.

David,

Thanks for your reply. Yes, we are using Web Mode and seldom uses the traditional mode. Monitoring running processes I observed that the back end sessions(engine) are sometimes too many, reaching 500+ and 250+ during normal days.

Cross checking this with my Oracle connections, I see that some of this engines are already tagged INACTIVE. Thus i proceed to kill them. But I somehow know that this could be not that safe, since INACTIVE Oracle connections only tells that the session is just idle and could be still in used.

We have issues where in a copy project or an update process will take hours to finish and at times will be hanging for hours hence I'm trying to analyze how to have a criterion when to kill an inactive engine.

thanks again.. :D

David Honey's picture

In web mode, the Synergy server manages a pool of sessions. There is both a minimum and maximum size of that pool. If a back end session in the pool has been idle for longer than certain time, the server should terminate that session in an orderly fashion.

I think the factory defaults (as defined in ccm.server.properties are:

1. Minimum of 3 sessions
2. Maximum of 10 sessions
3. Exit session after 900 seconds of being idle.

Killing engine processes under the feet of the Synergy server is just asking for trouble and is not the correct solution.

David.

robyu's picture
robyu replied on February 24, 2011 - 11:27am.

Thanks David for the insights. A PMR is already logged for IBM to check on this.

BTW, I went through the ccm.server.properties file and found the following:

#ccm.max.sessions - The maximum number of backend sessions. - ccm.max.sessions=20

Q: is this for the whole server or just for a single database?

# ccm.session.time.out - Amount of idle time before the #last backend sessions are timed out

ccm.session.time.out=never

Q:will it be advisable to turn to on with a valid time value?

Thanks..

David Honey's picture

That setting only applies to traditional mode. The default settings for Synergy 7.1 web mode as defined in the [i]ccm.server.properties[/i] file are:
[code]#===============================================
# Web server settings
#===============================================
cm.webserver.persistent.sessions= 3
cm.webserver.max.sessions= 10
cm.webserver.parallel.startups= 2

# Timeout peroids (in seconds)
cm.webserver.session.min.free.time= 900
cm.webserver.user.authentication.timeout= 300[/code]
The cm.webserver.max.sessions setting is per database. So if you have N databases, there could be a maximum of N*10 sessions.

Performance testing has only been performed with these factory default settings. I suggest that you leave these settings untouched until specifically directed to change them by Rational technical support in response to some specific issue.

Regards,
David.

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.