Forum Discussion

yozik_100692's avatar
Icon for Nimbostratus rankNimbostratus
Jan 31, 2012

is pycontrol slower than the perl API?

I'm in the process of porting over some perl code to python and have noticed that getting data back is much slower with pycontrol. Has anyone else noticed this?



the most basic example I have that demostrates this, well at lest for me, is getting a list of Virtual Servers. In perl getting the interface to the F5 and using get_list is very quick, undes 2 secs, while in python it takes 10+ secs.




any help or suggestions is welcomed.








15 Replies

  • it's one long perl script that uses CGI and ajax to build an interface for controlling irules and virtual servers. We needed something really dumbed down so that changing out irules for a given virtual server would be error proof.







  • Gotcha. If you do ever go back to Perl, let me know and I can help you out with any iControl code you need using SOAP::Lite. I've already got a few goodies in Perl dealing with iRule backup and archiving.



  • so to answer my question after some guidence, many thanks BTW, the delay in the python interface is really due to the fact that the wsdl has to be fecthed



    using something like



    b = pc.BIGIP(


    hostname = ip,


    username = username, user,


    password = pswd, password,


    fromurl = False,


    directory = '/mywsdls/',


    wsdls = ['LocalLB.VirtualServer'])




    now has the same response time as the perl interface.




    thanks everyone




  • Yozik, you've found the answer. That said, it's worth noting that *load* times (as opposed to call response times) will probably be faster in Perl (or Java) as well, because pyControl - really, Suds, the underlying client - parses the WSDL every time it is loaded. No, it's not ideal, but it does have its advantages...



    The Perl API is very much like the old school Soapy days in Python - you construct your own XML using native structures and pass them along. This is fast, but error prone. pyControl parses the WSDL and responds with explicit type definitions that adhere to the types defined in the WSDL, which I happen to like because it's less ambiguous: you create a type using the type factory and Suds does the right thing and serializes it correctly.



    Java is fast for a few reasons - primarily because it's always had killer native SOAP support, and it uses statically defined classes that gives you the advantages I mentioned above, but without the performance hit of parsing the WSDL every time you instantiate a client object. The only downside is that it's Java, so it's less script-y and user friendly, at least in my opinion.



    There have been multiple requests to allow Suds to serialize out the generated classes - you could pickle them and store them for later. This would be fantastic, but it's apparently really difficult to do, and since Suds relies so heavily on weak references it's not going to happen, probably ever. Python just doesn't pickle weakrefs...



    So you've landed on the right compromise, thanks to mhite. I suppose I could have just said that and left off all the commentary above :)



    --Matt Cauthorn
  • Thanks for the education, Joe!


    It just looks like it's using SOAP::Lite, I guess.



    Perl has always been my favorite.


    I've not had any issues with the iControl API using Perl, except that I wish there was a method like:



    my $output = getCliOutput("");



    Would be nice.