iControl Assembly Peformance

Thanks for posting this question, I love ones like this. B-).

 

I think "Serious Performance Issues" is a bit of an exaggeration. Compared to a binary protocol like CORBA, then, Yes, SOAP/Web Services are slower. But I wouldn't categorize it as a performance issue.

 

 

There is overhead for each SSL/HTTP request that is made. The iControl API's are designed as distinctive web services so each call will incur the overhead of establishing an SSL connection. We've designed the API's to enable "bulk" calling for multiple "like" objects per request. This way if you have 100 virtual servers, you can query the statistics for all 100 virtuals in a single call without incuring the tear-up/down of the SSL connection for each one.

 

 

So, it really depends on the number of calls you have to make along with the latency between your calling application and the target BIG-IP. It also partially depends on how busy your BIG-IP is. If it's running at or near capacity, then the calls will take a little longer to process as they get a lower priority in the system than the packet runtime.

 

 

I just requested the failover status on my BIG-IP using PowerShell through the iControl. NET assembly and the command took 0.026s.

 

 

PS C:\Users\Joe> Measure-Command {$ic.ManagementDBVariable.query( "failover.state" )}

 

Days : 0

 

Hours : 0

 

Minutes : 0

 

Seconds : 0

 

Milliseconds : 25

 

Ticks : 255908

 

TotalDays : 2.96189814814815E-07

 

TotalHours : 7.10855555555556E-06

 

TotalMinutes : 0.000426513333333333

 

TotalSeconds : 0.0255908

 

TotalMilliseconds : 25.5908

 

 

 

I ran a loop calling it 100 times and it took 1.366 seconds, and 1000 calls taking 13.659s. Granted, that's on an idle BIG-IP so I wouldn't expect a production system to have those numbers.

 

 

Compare that to a single SNMP GET request:

 

 

PS C:\Users\Joe> Measure-Command { snmpget bigip .1.3.6.1.4.1.3375.2.1.1.1.1.1.0 }

 

Days : 0

 

Hours : 0

 

Minutes : 0

 

Seconds : 0

 

Milliseconds : 55

 

Ticks : 551203

 

TotalDays : 6.37966435185185E-07

 

TotalHours : 1.53111944444444E-05

 

TotalMinutes : 0.000918671666666667

 

TotalSeconds : 0.0551203

 

TotalMilliseconds : 55.1203

 

 

 

It's twice as fast as the SNMP request, so the API is actually pretty efficient.

 

 

I'd love to hear your use-case for the API and what your requirements are for polling. Also, if you get to where you need to optimize your code to reduce round-trips, please post away, I'd be glad to help.

 

 

-Joe

Joe, fantastic reply. Really appreciate the level of detail. I'm not deep enough into this to replicate your calls but you prompted me to try a couple of things. The most interesting thing I found is it's the first call to the iControl assembly that seems to cause the most latency. In these two examples (calling each of 9 LTMs once and then calling 1 LTM 9 times it's the first call that accounts for approx 75% of the total run time. This is the code and below are the results. I made sure to capture only the time making the connection to the LTM and getting failover state. I would have expected each call to consume approx the same time within a reasonable variance. Not the case... anybody got any ideas why? On the plus side, it implies that I may have some up-front latency on my first call to any LTM in my code, but things get pretty sweet from there on out.

 

 

Module Module1

 

 

Sub Main()

 

Dim arrLTMs() As String = {}

 

Dim my_ltm As New iControl.Interfaces()

 

Dim StartTime As Double, EndTime As Double, dblTime As Double

 

Dim strState As String

 

For Each strLTM In arrLTMs

 

StartTime = Timer

 

my_ltm.initialize(strLTM, "", "")

 

strState = my_ltm.SystemFailover.get_failover_state.ToString()

 

EndTime = Timer

 

dblTime = EndTime - StartTime

 

Console.WriteLine(strLTM & " - " & strState & " - " & dblTime)

 

Next

 

Console.ReadLine()

 

End Sub

 

 

End Module

 

 

All nine LTMs once

 

-ltm-02 - FAILOVER_STATE_ACTIVE - 1.7424533999947

 

-ltm-01 - FAILOVER_STATE_STANDBY - 0.0600846000015736

 

-ltm-03 - FAILOVER_STATE_ACTIVE - 0.040056400001049

 

-ltm-04 - FAILOVER_STATE_ACTIVE - 0.110155099995609

 

-ltm-05 - FAILOVER_STATE_STANDBY - 0.110155100002885

 

-ltm-01 - FAILOVER_STATE_ACTIVE - 0.0500705000013113

 

-ltm-02 - FAILOVER_STATE_STANDBY - 0.0500704999940353

 

-ltm-01 - FAILOVER_STATE_ACTIVE - 0.0901269000023603

 

-ltm-03 - FAILOVER_STATE_ACTIVE - 0.0500705000013113

 

 

Same LTM nine times

 

-ltm-02 - FAILOVER_STATE_ACTIVE - 1.6823688000004

 

-ltm-02 - FAILOVER_STATE_ACTIVE - 0.0300423000007868

 

-ltm-02 - FAILOVER_STATE_ACTIVE - 0.0300423000007868

 

-ltm-02 - FAILOVER_STATE_ACTIVE - 0.0300423000007868

 

-ltm-02 - FAILOVER_STATE_ACTIVE - 0.0300423000007868

 

-ltm-02 - FAILOVER_STATE_ACTIVE - 0.0300423000007868

 

-ltm-02 - FAILOVER_STATE_ACTIVE - 0.0200281999932486

 

-ltm-02 - FAILOVER_STATE_ACTIVE - 0.0200282000005245

 

-ltm-02 - FAILOVER_STATE_ACTIVE - 0.0200282000005245

I just noticed the posting took out the indents from my code example. Not sure why, but I really do use them