Extremely slow response on first use

[jerrypapa]

Hi,

On CUCM 10.5, we are experiencing extremely slow response times (35-40 seconds) for the first request we send, with improved performance (5-6 seconds) for subsequent requests. It doesn't matter which order we send these requests, the first one is always very slow. Some example statements:

           sql = "select device.*, enduser.* from device, enduser, enduserdevicemap where device.pkid=enduserdevicemap.fkdevice and enduser.pkid=enduserdevicemap.fkenduser"

                sql = string.Format(@"select device.*, enduser.* from device, enduser, enduserdevicemap where device.pkid=enduserdevicemap.fkdevice and enduser.pkid=enduserdevicemap.fkenduser and enduser.userid = '{0}'", soeid)

                sql = "select * from numplan inner join callforwarddynamic on callforwarddynamic.fknumplan=numplan.pkid where callforwarddynamic.cfadestination is not null and callforwarddynamic.cfadestination != '' order by numplan.dnorpattern"

                sql = string.Format(System.Globalization.CultureInfo.InvariantCulture,"select * from numplan inner join callforwarddynamic on callforwarddynamic.fknumplan=numplan.pkid where callforwarddynamic.cfadestination is not null and callforwarddynamic.cfadestination != '' and numplan.dnorpattern = '{0}'", pattern)

[npetrele]

Looks like you're using C#.  I'm not a C# guy, but I find the same thing occurs with Java, only to a lesser extent (but that's probably because I'm not using SQL in my tests).  The first API call takes quite a while, after which the remaining calls run quicker.

I don't know what to tell you about the first call, except that you can expect some of the queries you've used as examples to be database-intensive, since you're doing things like inner joins. It's possible that the first query creates temporary tables and indices, and the subsequent calls re-use them. If you have a DBA on staff familiar with Informix, you might want to ask how you can optimize the queries, if possible.

You can also speed up the subsequent calls by grabbing and re-using JSESSIONID to continue using the same Tomcat session for multiple API calls.  The new AXL documentation (hasn't bee posted yet, but will be soon) provides a little more detail on that.

[dstaudt]

Are you using a SOAP consumer/compiler (i.e. wsimport or wsdl.exe) to create AXL stub code?  If so, since the AXL API is huge, this stub code is even more huge, and can take a long time to initialize.  Some workarounds:

- Find a way to init the AXL module prior to when you need to make requests

- Prune down either the WSDL itself or the generated stub code to remove requests/responses and other definitions that are not applicable to your application

- Don't use WSDL auto-generated stub code, and use AXL as an XML over HTTP interface (using far lighter weight XML or HTP request objects) rather than as a SOAP interface.

It may be helpful to carefully step through your app, watch network traffic, and review the AXL logs to try and pinpoint where the initial bottleneck is happening.  If you are doing a query which requires a lot of processing and returns a lot of data, then it's possible it may just take a long time for the first query to get the needed data into memory cache in the CUCM database.

As Nick suggests, you will want to be conservative and careful about pulling data from CUCM - it is a real-time, mission-critical system, and if you can retrieve data in smaller chunks and do additional processing (like joins) in your app, that is well advised.  For example the first query appears to scan, join and return all of the data from device and enduser tables - which can potentially have tens of thousands of rows, each with hundreds of fields.