topic Re: AXL performance/limitation in CUCM 10.5 in Management

AXL performance/limitation in CUCM 10.5

fleclair — Fri, 04 Mar 2016 06:00:09 GMT

Hi team,

In CUCM 9.1 documentations, they indicates the following in terms of AXL query limitation and how CUCM is doing throttling :

*************************************

Dynamic Throttling of Requests (as per http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/devguide/8_6_1/xmldev-861/axl.html#wp1219778)

Unified CM releases earlier than 7.0 included the AXL service parameter MaxAXLWritesPerMinute, which has a default value of 50 and maximum value of 999. This service parameter designates the maximum number of write requests that AXL can encounter and process in one minute. Unified CM 7.0 includes a new throttling mechanism. The MaxAXLWritesPerMinute service parameter has been deprecated.

The new throttling mechanism takes into account the dynamic state of Unified CM. It considers the number of outstanding change notifications across the Unified CM cluster at any given time. If a node has more than 1,500 outstanding change notifications, AXL stops processing write requests until the outstanding change notifications are below 1,500. During throttling, HTTPS Status-Code: 503 Service Unavailable response and sets AXL performance counters which can be viewed using RTMT. When a 503 Service Unavailable response is returned, Cisco recommends that the application sleep for a number of seconds or milliseconds (as determined by the developer) to allow pending write requests to be processed. The application should then continue submitting requests.

There are two AXL performance counters:

•ThrottleCount—Determines number of times Administrative AXL throttling has been engaged.

•ThrottleState—Determines the state of AXL throttling. That is, whether AXL throttling is currently active (throttling is engaged).

The AXL error message for throttling remains same as in earlier versions of Unified CM. There is no change required to AXL applications.

For example, consider an application that makes 1,000 phone insertions in 30 seconds. Assume that these insertions cause 2,000 change notifications to various applications such as Unified CM and Cisco TFTP, and that within 10 seconds all change notifications are consumed. In this situation, by the 40^th second, the number of outstanding change notifications is zero and the throttling mechanism does not take effect. However, if these change notifications are not consumed, the throttling mechanism does take effect and write requests are throttled until the outstanding change notification value falls below 1,500.

The throttling mechanism considers the capacity of the Unified CM cluster to consume the change notifications that generated from all the write activities to the Unified CM database. In this way, it is dynamic. As long as all change notifications are consumed at a rate that is equal to or higher than the rate at which change notifications are generated, throttling does not take effect.

able 2-11 AXL Query Limits
Writes Per Minute	Maximunm of 1500 Write requests
Reads Per Minute	No limit for Read requests.
Total Records	No limits for total number of records. But size of total recordes must be less than 8MB per request and 16MB is the maximum buffer allocated for parallel processing of requests.

*************************************

But I'm unable to find the equivalent indications in CUCM 10.5 ? I found the following but it contains less detail than in v9.1 :

https://developer.cisco.com/site/axl/documents/axl-developer-guide-v11-0/#data-throttling-and-performance

Can you help me clarifying the limits in 10.5 please ?

Many thanks,

Francois

Re: AXL performance/limitation in CUCM 10.5

jkrohn — Fri, 04 Mar 2016 08:49:31 GMT

The actual limits against which the algorithm throttles the requests should not be used by any application using AXL to implement some client side throttling. As the developer guide states the applications should instead implement a back-off algorithm to retry the request after a reasonable delay (multiple seconds). An exponential back-off algorithm might be the best solution.

Re: AXL performance/limitation in CUCM 10.5

sergio.delgado — Tue, 12 Jul 2016 15:52:14 GMT

In which cases does AXL API returns error 503? What are the limits of the API (reads per second), relative to the executeSQLQuery method?

Thanks,

Sérgio

Re: AXL performance/limitation in CUCM 10.5

sergio.delgado — Tue, 19 Jul 2016 14:56:22 GMT

Any feedback would be much appreciated!

Thanks!

Re: AXL performance/limitation in CUCM 10.5

dstaudt — Fri, 09 Sep 2016 20:39:23 GMT

I don't believe there are any particular hard-coded or algorithmic limits in the AXL service code for limiting the rate of AXL read requests (standard requests or executeSqlQuery), i.e. per second. The service will fulfil the requests at best effort, and applications should conduct load testing to determine reasonable sustainable querying rates.

As mentioned above, apps should be prepared to handle a 503 or other standard HTTP web server failure codes resiliently, ideally with a back-off algorithm for repeated failures.

Re: AXL performance/limitation in CUCM 10.5

stefania.oliviero@farnetworks. — Tue, 28 Feb 2017 08:43:13 GMT

If I have a cluster of 8 CUCM, AXL request must be sent only to publisher or I can send AXL request also to the subscriber nodes ?

Re: AXL performance/limitation in CUCM 10.5

dstaudt — Tue, 28 Feb 2017 18:39:36 GMT

Crossposted here: AXL request to publisher and Subscriber nodes