Kamailio SIP Server Wiki

User Tools

Site Tools

Trace:
devel:config-engines

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
Next revision Both sides next revision
devel:config-engines [2016/05/03 13:47]
miconda [To-Do] 		devel:config-engines [2016/05/03 18:34]
miconda
Line 382: Line 382:
 </code> </code>
  
-===== Examples =====+===== Basic IP Telephony Config Example =====
  
 Some examples of configuration files using the native, Lua or Python interpreter are available in Kamailio source tree inside the **examples/kemi** folder - online at github: Some examples of configuration files using the native, Lua or Python interpreter are available in Kamailio source tree inside the **examples/kemi** folder - online at github:
Line 390: Line 390:
 The configuration file to start with is **kamailio-basic-kemi.cfg**: The configuration file to start with is **kamailio-basic-kemi.cfg**:
  
-{{url>https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi.cfg}}+  * https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi.cfg
  
 You can either rename it to kamailio.cfg or use **-f** command line option to point to it. You can either rename it to kamailio.cfg or use **-f** command line option to point to it.
Line 396: Line 396:
 If started without any change and no define in command line, then Kamailio will continue to load the routing blocks in the native language, stored in the file **kamailio-basic-kemi-native.cfg**: If started without any change and no define in command line, then Kamailio will continue to load the routing blocks in the native language, stored in the file **kamailio-basic-kemi-native.cfg**:
  
-{{url>https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-native.cfg}}+  * https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-native.cfg
  
 If you define WITH_CFGLUA inside **kamailio-basic-kemi.cfg** or provide the command line parameter **-A WITH_CFGLUA**, then Kamailio will load the routing blocks in the Lua language, stored in the file **kamailio-basic-kemi-lua.lua**: If you define WITH_CFGLUA inside **kamailio-basic-kemi.cfg** or provide the command line parameter **-A WITH_CFGLUA**, then Kamailio will load the routing blocks in the Lua language, stored in the file **kamailio-basic-kemi-lua.lua**:
  
-{{url>https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-lua.lua}}+  * https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-lua.lua
  
  
 If you define WITH_CFGPYTHON inside **kamailio-basic-kemi.cfg** or provide the command line parameter **-A WITH_CFGPYTHON**, then Kamailio will load the routing blocks in the Python language, stored in the file **kamailio-basic-kemi-python.py**: If you define WITH_CFGPYTHON inside **kamailio-basic-kemi.cfg** or provide the command line parameter **-A WITH_CFGPYTHON**, then Kamailio will load the routing blocks in the Python language, stored in the file **kamailio-basic-kemi-python.py**:
  
-{{url>https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-python.py}}+  * https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-python.py
  
 Combining **kamailio-basic-kemi.cfg** with **kamailio-basic-kemi-native.cfg** results more or less in the **kamailio-basic.cfg** from the **etc/** folder in Kamailio source tree. The Lua and Python scripts are offering the same features, but written in another language. Combining **kamailio-basic-kemi.cfg** with **kamailio-basic-kemi-native.cfg** results more or less in the **kamailio-basic.cfg** from the **etc/** folder in Kamailio source tree. The Lua and Python scripts are offering the same features, but written in another language.
Line 457: Line 457:
 Testing was done for registrations with user authentication, using **sipp** tool with parameters **-m 1000 -r 50** on the same VirtualBox system with Kamailio. Each test for different interpreters was doing 1000 registrations with different caller ids. Each first REGISTER was challenged for authentication, so practically there were 2000 REGISTER requests: first REGISTER being challenged with 401, the follow up was receiving 200ok as the authentication succeeded. Testing was done for registrations with user authentication, using **sipp** tool with parameters **-m 1000 -r 50** on the same VirtualBox system with Kamailio. Each test for different interpreters was doing 1000 registrations with different caller ids. Each first REGISTER was challenged for authentication, so practically there were 2000 REGISTER requests: first REGISTER being challenged with 401, the follow up was receiving 200ok as the authentication succeeded.
  
-The values are in micro-seconds (1 / 1 000 000 of a second) and represents the average execution time, the minimum execution time and the maximum execution time.+The values are in micro-seconds (1 / 1 000 000 of a second) and represents the average execution time, the minimum execution time and the maximum execution time for request_route{...} block (or the equivalent of).
  
 The results were: The results were:
Line 474: Line 474:
 Remarks: Remarks:
  
-  * the avverage was between 300 and 400 micro-seconds, resulting in a capacity of 2500 to over 3000 REGISTERs/second. CPU usage per Kamailio SIP worker process was around 1%. Again, not targeting to measure the capacity, the config runs with 4 SIP workers, increasing that will increase the capacity as database operations were involved to fetch the username and password via **auth_db** module.+  * the average was between 300 and 400 micro-seconds, resulting in a capacity of 2500 to over 3000 REGISTERs/second. CPU usage per Kamailio SIP worker process was around 1%. Again, not targeting to measure the capacity, the config runs with 4 SIP workers, increasing that will increase the capacity as database operations were involved to fetch the username and password via **auth_db** module.
   * the test was run many times, the Native and Lua execution were close to each other, many times Lua being faster, but again, at small difference   * the test was run many times, the Native and Lua execution were close to each other, many times Lua being faster, but again, at small difference
   * no big surprise as Lua is calling directly the C bindings and its interpreter is written also in C. With the config used in the tests, the Lua script doesn't do much of specific Lua operations, it mainly executes the functions exported by Kamailio   * no big surprise as Lua is calling directly the C bindings and its interpreter is written also in C. With the config used in the tests, the Lua script doesn't do much of specific Lua operations, it mainly executes the functions exported by Kamailio
-  * Python is slower comparing to Native and Lua, but not that much as one may expect. I can still deal with 2500 REGISTERs/second. Even more, some of its latency comes from the way **app_modules** is designed, to create a Python object from Kamailio's SIP message structure. That involves cloning (and freeing) of each SIP message to be represented in Python. Lua uses the Kamailio core SIP message structure, like the Native interpreter without any overhead. Same approach should be possible for **app_python**, current approach is more object-oriented at expense of using more resources.+  * Python is slower comparing to Native and Lua, but not that much as one may expect. It can still deal with 2500 REGISTERs/second. Even more, some of its latency comes from the way **app_modules** is designed, to create a Python object from Kamailio's SIP message structure. That involves cloning (and freeing) of each SIP message to be represented as an object in Python. Lua uses the Kamailio core SIP message structure, like the Native interpreter without any overhead. Same approach should be possible for **app_python**, current approach is more object-oriented at expense of using more resources.
   * in some tests, the maximum execution time was between 5000 and 10000 micro-second, but for all interpreters, suspecting to be related to other tasks done by guest OS (which was running a web browser as well). The average didn't result in big differences, even in such cases. Also, sometimes the minimum was below 1 micro-second.   * in some tests, the maximum execution time was between 5000 and 10000 micro-second, but for all interpreters, suspecting to be related to other tasks done by guest OS (which was running a web browser as well). The average didn't result in big differences, even in such cases. Also, sometimes the minimum was below 1 micro-second.
  
devel/config-engines.txt ยท Last modified: 2017/11/20 14:31 by miconda

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki