Limit on Concurrent Session

[Ed James]

Hello,

Is there a concurrent usage limit on either the uniMRCP client or uniMRCP server or indeed with Google ? We have a client who wants to investigate using Google TTS for playing fault messages to clients and there could potentially be thousands of concurrent calls. 

Any comments etc.. would be very helpful.

Thanks

Ed James 

[Arsen Chaloyan]

Hello Ed,

There are various limits that need to be properly accounted for all the components.

MRCPv2 connections

The default value of max MRCPv2 connections (max-connection-count) is set to 100 for both the client and server. You may or may not need to adjust this parameter depending on whether a shared/existing or a new connection is supposed to be used between the MRCP client and server for each MRCP session. The behavior is determined via SDP offer/answer. The client may offer to use an existing or new connection, the server would comply but may enforce to use new if max-shared-use-count is reached or force-new-connection is set to true.

RTP Streams

The default configuration has a range of 1000 ports (rtp-port-min, rtp-port-max) for both the client and server, which would serve up to 500 concurrent RTP sessions (a pair of RTP and RTCP ports).

Load Distribution

It would be recommended to distribute the load evenly between two or more UniMRCP server instances. You may interconnect a pair of clients with a pair of servers and balance the load in simple round robin mode.

Google Account

You would likely hit the default usage quotas on a Google account.

https://cloud.google.com/text-to-speech/quotas

It would be possible to use different accounts per UniMRCP server instance. Or you may need to contact Google to raise the default limits on your account(s).

TTS Caching

If you are going to use the caching routine provided by the GSS plugin (>= 1.8.0), then this will help reduce traffic to Google, but you may need to properly provision the max cache records to be stored on UniMRCP server, which would depend on your use cases.

This would be the general guidelines, I think. Please let me know if you have any follow-up questions.

--
You received this message because you are subscribed to the Google Groups "UniMRCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unimrcp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unimrcp/803c6390-20b6-45ff-bf74-e4ab8ec1ef4bn%40googlegroups.com.

--

Arsen Chaloyan
Author of UniMRCP
http://www.unimrcp.org

[Ed James]

Hi Arsen,

Thanks for your response, just for my understanding as an example on our test kit for the MRCP connections we have the following:

Server: 

      <max-connection-count>100</max-connection-count>

      <max-shared-use-count>100</max-shared-use-count>

      <force-new-connection>false</force-new-connection>

 Client:

"<max-connection-count>100</max-connection-count>"

"<offer-new-connection>false</offer-new-connection>"   // Reuse an existing connection if there is one

 

So we’ve got 100 connections all reusable but does that mean we are limited to 100 concurrent MRCP sessions and the reusability is that a TCP connection is reused for a series of sequential MRCP exchanges instead of creating a new TCP connection for each MRCP exchange ? 

If we wanted 500 concurrent sessions as a max then we would need max-connection-count of at least 500 so in other words you can't share the sessions over a single TCP connection ?

Do you know if there is an effective limit (maybe dictated performance) on the max-connection-count ?

Thanks

Ed   

[Arsen Chaloyan]

Hi Ed,

In brief, given your settings, you can safely discard this topic, as the limit in the MRCPv2 connections would never reach, unless you connect 100 different clients to the same server.

Now more detailed answers to your questions below.

> So we’ve got 100 connections all reusable but does that mean we are limited to 100 concurrent MRCP sessions

No, the concurrency is not limited with this setting. A single connection can be used by an unlimited number of concurrent MRCP sessions placed between the same client and server.

> and the reusability is that a TCP connection is reused for a series of sequential MRCP exchanges instead of creating a new TCP connection for each MRCP exchange ?

If you refer to request/response messages, then they are carried over a single connection. Furthermore, the same connection will/can be used for many concurrent request/responses.

> If we wanted 500 concurrent sessions as a max then we would need max-connection-count of at least 500 so in other words you can't share the sessions over a single TCP connection ?

No, you do not have to set it to 500, unless the client offers to establish a new connection per MRCP session ( <force-new-connection>true</force-new-connection> ) and/or the server enforces the new connection (<force-new-connection>true</force-new-connection> )

> Do you know if there is an effective limit (maybe dictated performance) on the max-connection-count ?

There are live systems processing hundreds of concurrent sessions with both options (1) a single connection being reused and (2) a new connection being established per session. Generally speaking, the former would be more preferable performance-wise. There is one catch, though. The memory allocated out of the connection pool is released only when the connection is no longer used (no associated sessions). That is why the lifetime of connections is limited by another parameter <max-shared-use-count>100</max-shared-use-count> to prevent the connection memory pool to possibly grow unconditionally.

Please let me know if you need further clarifications.

To view this discussion on the web visit https://groups.google.com/d/msgid/unimrcp/e9791957-0f22-47de-b6c1-f6f6a4424ca1n%40googlegroups.com.