[SR-Users] Python KEMI performance

[Daniel-Constantin Mierla]

Hello,


On 13.09.18 22:02, Henning Westerholt wrote:
> Am Donnerstag, 13. September 2018, 18:23:25 CEST schrieb Aleksandar Sosic:
>> is there anyone here that has done a performance testing measurements
>> between native kamailio config file and full python kemi instance of
>> kamailio?
>>
>> I've read somewhere that the python kemi code was 30% slower. Why is
>> that and are there any plans on trying to improve the performance of
>> python kemi?
> Hello Aleksandar,
>
> have a look to this talk from Daniel:
>
> https://www.youtube.com/watch?v=cp3TZkcpFUQ
>
> Python is slightly slower because it needs a dynamic object during the cfg 
> execution. But with today fast and many CPU cores in a server, I don't think 
> that should be an issue in a real-world deployment.
>
> The 30% slower is just for the pure configuration execution. The overall 
> capacity of a Kamailio server depends normally more on the I/O performance 
> (database, network..) than of CPU capacity. 
>
> So my expectation would be that you see in a normal proxy or registrar 
> configuration maybe a few percent more CPU load, in many cases it should be 
> not really noticeable. 
>
>
>
I am not the original developer of app_python, nor an experienced python
developer (I would rather say the opposite here), so that was my guess
for a source of slowness compared with the other embedded interpeter --
app_lua creates an object for each sip message it processes, so it need
to initiate its, attach fields and methods to it, etc ... then destroy it.

The other interpreters, they export KSR as a static module, done once at
startup and the sip message is just a reference to the C structure of
kamailio, kept in a global pointer per process, so really minimal
overhead for processing each sip message, because no new complex
structure/object is created.

So this approach can be something to do in app_python/2, but I am not
familiar with embedding python, I just exported more functions based on
what was existing in the module. Contributors are welcome here!

On the other hand, python is know to be slower than lua, so that can a
bit of penalty always.

However, as Henning pointed out, I don't think interpreter performances
are a big concern, eventually you can scale horizontally, where the
benefits are the power and additional extensions of that scripting
language.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com