About the UserThreads parameter

[Pablo Maldonado]

Hello, I wanted to know if the UserThreads server parameter is what limits the sessions in it. In other words, if UserThreads = 6 is set, there could not be more than 6 sessions at the same time, including user connections and agents. Pablo Maldonado

[Ronald Jeninga]

Hi Pablo,

yes, you've understood that correctly.

It isn't a problem to configure a safe distance to the expected number of concurrent sessions.

E.g. if you expect 45 jobservers and 15 users, you'd need 60 UserThreads. If you configure 80, you'd have enough room to cover the unexpected.

With the List Sessions command (or the Sessions tab in the SysInfo form), you can see the currently active sessions.

Best regards,

Ronald

[Pablo Maldonado]

Hello Roland,

As impact on the consumption of memory resources and cpu each new session established in the system or does not have a great impact.

If you could help me how to calculate this I would appreciate it.

Thank you so much

Pablo Maldonado

[Ronald Jeninga]

Hi Pablo,

as long as you don't exaggerate the values, the parameter is pretty harmless.

Each active user connection consumes one TCP port. This means that the maximum number of sessions lies around 64,000.

But of course the OS configuration that defines the maximum number of file handles per process plays a role here as well.

This means that any value larger than 64,000 is nonsense.

Unused user connections are represented by a null value in a fixed size table.

Since the number of entries in this table is comparatively low (usually less than 100, in some environments maybe 2000), the search for an empty slot is a simple linear search.

Hence the complexity of the process is O(n). But that doesn't really have an impact on the CPU usage.

The memory usage of an unused slot is negligible (I'd guess 16 bytes per entry).

As you can see, unused connections do cause costs, but if you configure a reasonable value, you won't notice.

To calculate a reasonable number, you start with the number of active jobservers.

This is a pretty stable number (after a while you don't install several new jobservers almost daily), and each jobserver will consume one connection.

The number of users is harder to determine. The web GUI will only allocate a relatively low number of connections (at most one for each active concurrent request).

If you have, let me say, 30 co-workers that work with the system, it is very likely that 5 or 6 user connections will be sufficient to handle the requests.

If your jobs do things like dynamic submits, set or get parameter values , you need some user connections to cover that as well.

But again, even if you have a lot of Jobs running, it is unlikely they'll all need a connection  at the same time. I'd estimate that another 5 or 6 user connections will do.

Hence

#jobservers + 6 + 6

will be a good starting point. And in order to cover the more unlikely scenarios, I'd add something like 20% connections.

Bottom line:

1.2 * (#jobservers + 12)

as a rule of thumb should work in most environments.

In case of a very large number of jobservers those 20% can be safely reduced.

Does this help?

Best regards,

Ronald

[Pablo Maldonado]

Hello Roland,

Yes, it really helps what you explain to me.