Forum Discussion

scott_nixon_825's avatar
scott_nixon_825
Historic F5 Account
Apr 05, 2005

3DNS 4.6.3 SOAP is slow while being queried

3DNS 4.6.3 build 82

 

 

Our 3DNS that uses SOAP is extremley slow the time it takes to run

 

against the perl script they have that queries 3DNS.

 

It takes up 15 min to process the queries.

 

 

Customer perl script works as follows:

 

 

Calls routines based on the documentation in the API from F5: GET the data centers, wideip and VS in the wide IP/pool. For 18 wide-IPs (3 VsB objects each), it takes 14 seconds. For 1 wide-IP (2 VsH objects), it takes 4 seconds.

 

Current SOAP machine is 2.66Ghz processor with 512MB memory. 12393K running process, spending most of it's time in sbwait and connect status. Load level of the machine is 0, I don't see swap or paging usage.

 

Each connection/API call takes a HTTPS session startup, that's why it's slow.

 

 

Please note that the customer is commenting on the overall performance

 

problem on the 3DNS API. Also note that he's calling several methods

 

to get the data he wants.

 

Perhaps helping the customer to derive desirable bulk methods?

 

The bulk methods may be the only way to resolve the performance problem.

 

 

Since the performance metrics are already known to development I am

 

submitting this issue to dev central

 

Hoping DevCentral would be able to better answer the customer's questions

 

regarding how to get the data he desires using bulk methods instead of

 

using individual calls to acquire it.

 

2 Replies

  • Currently, there is no way to add HTTP Keep-alive support to the SOAP::Lite client libraries so the overhead of the SSL negotiation on each method call is unavoidable.

     

     

    So, that leaves us with the total time being a function of the number of calls times the time each call takes

     

     

    total_time = num_call * time_per_call

     

     

    The time per call is fairly constant in the 500ms (+/- 200ms) range for the SOAP::Lite libraries so this should scale linearly with the number of calls made.

     

     

    10 calls => 5s.

     

    100 calls => 50s.

     

    1000 calls => 8m 20s.

     

    2000 calls => 16m 40s.

     

     

    If you could post a logic flow of the application and which calls are made where, I can comment on whether there is a more optimal way to use the calls or whether alternate ways to get at the data would be more relevant.

     

     

    -Joe
  • I've been looking at this for a while and as luck will have it, in version 0.65 of SOAP::Lite, the authors have exposed the HTTP request object allowing custom insertion of HTTP headers. This allows the user, in the client code, to inject the Authenticate header thus eliminating the need for the infamous request-with-no-auth, 401-error, request-with-auth, 200-success. By including the following line after your SOAP::Lite object instantiation, you'll bypass half of the round trips needed!

     

     

    Here's a sample taken from the SystemInfo.pl sample from the SDK.

     

     

     
     ... 
     $soap = SOAP::Lite 
       -> uri('urn:iControl:System/SystemInfo') 
       -> proxy($sURL); 
     $soap->transport->http_request->header 
     ( 
       'Authorization' => 'Basic ' . MIME::Base64::encode("$sUID:$sPWD", '') 
     );

     

     

    I haven't performed timing tests yet, but this should reduce the total time by a good chunk. Not 50%, but a good chunk.

     

     

    -Joe