AXL Performance CUCM 11.5

[mataxl]

Hello,

I have a java application that handle a lot of request axl at same time on CUCM 11.5.

For example, i need to make hypothetically 30 queries per second (both select and update) on cluster cucm.

Of course in my application i implemented a queue handler mechanism (so actually the number of queries is less), and I've already followed the best practices for example implementing retry mechanism to handle error 503, and making select query on subscriber.

Its all ok, every request are handled, but i noticed the callmanager replies very slowly after amount of time respect at start.

I'd like to know if is normal, and if there is any tricks to increment the performance on CUCM (for example increment any paramenters...).

I searched any declared limit of axl requert per second but i didnt find anything. Someone can give me any advice??

Thanks

Mattia

[dstaudt]

A few thoughts...

• AXL is not designed to be an API for implementing changes effecting features in 'real-time' (for example changes which need to happen within seconds) - it's intended for general administrative provisioning and configuration (i.e. changes that can take an indeterminate amount of time - possibly tens of seconds, or minutes).  It would be helpful to understand in a fair amount of detail exactly what your application is doing - it may be possible that another API intended for real-time feature implementation (e.g. JTAPI or CURRI) is a better fit for the use-cases.
  An unlikely, but still real, worse-case scenario would be if your app started impacting CUCM call processing or core-feature performance - if it was determined that the app is attempting to do large-scale real-time feature implementation, Cisco may decline to troubleshoot/investigate/fix the problem and require your solution be removed before continuing.
• Depending on the data being read and/or written, it may be a good idea to implement a cache of some kind.  For example, info like a phone description seldom changes; as you lookup descriptions for phones you could store them in a local cache for 24 hrs, marking them stale if last updated > 24 hrs.  Update caching is harder, but you could possibly batch specific updates for 5 minutes (e.g. again, phone descriptions) and then do a <executeSqlUpdate> sending all updates received in the last 5 min.  (Your SQL can have separate SQL commands separated by commas ';'
• AXL read requests can be executed against any CUCM node including subscribers, so you could potentially spread out the load (careful is you start using call-processing nodes.)  Due to the one-way pub->sub database replication architecture, AXL updates should all be done against the publisher (though tables of the name 'XXXXdynamic' may be bi-directionally replicated.)  However, if you update on the Pub and try to immediately re-read the data from a Sub, you may get stale data if replication hasn't completed.
• It is important when using AXL that the HTTP connection be preserved for subsequent requests via HTTP 1.1 connection-reuse (do not specify the header 'Connection: close'): https://en.wikipedia.org/wiki/HTTP_persistent_connection
• Even more important is re-using the authentication/session by re-sending the CUCM Tomcat cookie (received in the response to the initial AXL request) with each subsequent request: https://developer.cisco.com/docs/axl/#!axl-developer-guide/data-throttling-and-performance

[mataxl]

Hello,

many thanks about the tips.

I know AXL is not designed to be a real-time api, but its the only way, so please tell me if what im trying to do is impossible.

My application is a kind of EM (unfortunatly i can't use it), so i have to update a lot of object on CUCM when a user logged-in on his pc in a company (there is a custom client installed on every PC that started on boot).

As u can image i have to handle a lot of request per second, in a short interval of time.

I can't use a cache, and i already use the same http-connection.

I have one question: you suggested to don't make the update on publisher, because the db replication is one way (pub -> sub), but to increment performance i've tried to do one test aiming on subscriber and it seems to work.

But how is possible? Is the queue of operations common to the cluster (publisher, and many subscriber)? After received an update request, does the subscriber "deliver" the operation on publisher? Is efficient?? Can it increment the performance?? Any contraindications?

Thank you very much for your availability.

[dstaudt · Accepted solution]

This article does a pretty good job of describing CUCM DB replication, and covers which configs are pub->sub vs. full-mesh replicated: http://www.ciscopress.com/articles/article.asp?p=2743756&seqNum=8