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