openSIPS | Resources / TestsProfiling

April 24, 2013, at 02:24 PM by 109.99.235.212 -

Changed lines 1-32 from:

Code profiling for OpenSIPS 1.6

Why profiling

We decided to run some profiling on the code of OpenSIPS 1.6, to learn (and not estimate and guess) which are the most CPU consuming parts of OpenSIPS at this moment - in other words, what is the most expensive task (like parsing, running script, etc) performed by OpenSIPS when it comes to CPU usage. Note that with profiling you learn only the CPU usage and not also the I/O dead times - the profiling is actually taking place only when the OpenSIPS processes do own the processor; while they are suspended in I/O's, no profiling is done, so the I/O dead times will not be reflected in the profiling results.

The profiling is about pure CPU usage.

Profiling scenario

The profiling was done having OpenSIPS proxy as an intermediary between a SIPp server and a SIPp client (using standard UAC-UAS scenarios).

OpenSIPS was running in no fork mode (only one worker process) and for configuration the default config file was used. The only change in the config was to enable dialog support (via create_dialog() for initial INVITEs).

Profiling was done with the gprof profiling tool for 10 million calls with a rate of 2000 simultaneous calls.

Results

The detailed results of the test are available either in a text format or displayed in the chart bellow, http://www.opensips.org/uploads/Resources/exec_time.gif which contains the overall results for the following groups:

time spent in parsing SIP messages (PARSE - green)
time spent in building SIP messages (BUILD - blue)
time spent in generic execution, like script logic or network ops (EXEC - red )
time spent in memory ops - alloc + free (MEM - yellow)

Conclusions

If you look only from the CPU usage perspective, you can see that managing the SIP messages (parsing and building) takes almost half of the CPU usage for OpenSIPS.

This information is actually useful for both developers and script writers to understand what is the impact of the functions they implement or use - abusing functions that do trigger parsing or not repeating the same parsing ops several times in different parts of the script.

to:

(:redirect About.PeformanceTests-CodeProfiling quiet=1:)

October 09, 2009, at 09:36 AM by bogdan -

Changed line 30 from:

If you look only from the CPU usage perspective, you can see that managing the SIP messages (parsing and building) takes more than 50% of the CPU usage for OpenSIPS.

to:

If you look only from the CPU usage perspective, you can see that managing the SIP messages (parsing and building) takes almost half of the CPU usage for OpenSIPS.

October 08, 2009, at 05:57 PM by iulia_bublea -

Changed line 5 from:

We decided to run some profiling on the code of OpenSIPS 1.6, to learn (and not estimate and guess) what are the most CPU consuming parts of OpenSIPS at this moment - in other words, what is the most expensive task (like parsing, running script, etc) performed by OpenSIPS when it comes to CPU usage. Note that with profiling you learn only the CPU usage and not also the I/O dead times - the profiling is actually taking place only when the OpenSIPS processes do own the processor; while they are suspended in I/O's, no profiling is done, so the I/O dead times will not be reflected in the profiling results.

to:

We decided to run some profiling on the code of OpenSIPS 1.6, to learn (and not estimate and guess) which are the most CPU consuming parts of OpenSIPS at this moment - in other words, what is the most expensive task (like parsing, running script, etc) performed by OpenSIPS when it comes to CPU usage. Note that with profiling you learn only the CPU usage and not also the I/O dead times - the profiling is actually taking place only when the OpenSIPS processes do own the processor; while they are suspended in I/O's, no profiling is done, so the I/O dead times will not be reflected in the profiling results.

October 08, 2009, at 05:55 PM by iulia_bublea -

Changed line 5 from:

We decided to run some profiling on the code of OpenSIPS 1.6, to learn (and not estimate and guess) what are the most CPU consuming parts of OpenSIPS at this moment - in other words, what is the most expensive task (like parsing, running script, etc) performed by OpenSIPS when come to CPU usage. Note that with profiling you learn only the CPU usage and not also the I/O dead times - the profiling is actually taking place only when the OpenSIPS processes do own the processor; while they are suspended in I/O's, no profiling is done, so the I/O dead times will not be reflected in the profiling results.

to:

We decided to run some profiling on the code of OpenSIPS 1.6, to learn (and not estimate and guess) what are the most CPU consuming parts of OpenSIPS at this moment - in other words, what is the most expensive task (like parsing, running script, etc) performed by OpenSIPS when it comes to CPU usage. Note that with profiling you learn only the CPU usage and not also the I/O dead times - the profiling is actually taking place only when the OpenSIPS processes do own the processor; while they are suspended in I/O's, no profiling is done, so the I/O dead times will not be reflected in the profiling results.

October 08, 2009, at 05:48 PM by iulia_bublea -

Changed lines 5-6 from:

We decided to run some profiling on the code of OpenSIPS 1.6, to learn (and not estimate and guess) what are the most CPU consuming parts of OpenSIPS at this moment - on other words, what is the most expensive task (like parsing, running script, etc) performed by OpenSIPS when come to CPU usage. Note that with profiling you learn only the CPU usage and not also the I/O dead times - the profiling is actually taking place only when the OpenSIPS processes do own the processor; while they are suspended in I/O's, no profiling is done, so the I/O dead times will not be reflected in the profiling results.

to:

We decided to run some profiling on the code of OpenSIPS 1.6, to learn (and not estimate and guess) what are the most CPU consuming parts of OpenSIPS at this moment - in other words, what is the most expensive task (like parsing, running script, etc) performed by OpenSIPS when come to CPU usage. Note that with profiling you learn only the CPU usage and not also the I/O dead times - the profiling is actually taking place only when the OpenSIPS processes do own the processor; while they are suspended in I/O's, no profiling is done, so the I/O dead times will not be reflected in the profiling results.

Changed line 30 from:

If you look from only the CPU usage perspective, you can see that managing the SIP messages (parsing and building) takes more than 50% of the CPU usage for OpenSIPS.

to:

If you look only from the CPU usage perspective, you can see that managing the SIP messages (parsing and building) takes more than 50% of the CPU usage for OpenSIPS.

October 08, 2009, at 05:37 PM by iulia_bublea -

Changed lines 22-25 from:

time spent in parsing SIP messages (PARSE)
time spent in building SIP messages (BUILD)
time spent in generic execution, like script logic or network ops (EXEC)
time spent in memory ops - alloc + free (MEM)

to:

time spent in parsing SIP messages (PARSE - green)
time spent in building SIP messages (BUILD - blue)
time spent in generic execution, like script logic or network ops (EXEC - red )
time spent in memory ops - alloc + free (MEM - yellow)

October 08, 2009, at 05:36 PM by 81.180.102.217 -

Changed lines 3-4 from:

Profiling scenario

to:

Why profiling

We decided to run some profiling on the code of OpenSIPS 1.6, to learn (and not estimate and guess) what are the most CPU consuming parts of OpenSIPS at this moment - on other words, what is the most expensive task (like parsing, running script, etc) performed by OpenSIPS when come to CPU usage. Note that with profiling you learn only the CPU usage and not also the I/O dead times - the profiling is actually taking place only when the OpenSIPS processes do own the processor; while they are suspended in I/O's, no profiling is done, so the I/O dead times will not be reflected in the profiling results.

The profiling is about pure CPU usage.

Profiling scenario

Changed lines 13-15 from:

OpenSIPS was running in no fork mode (only one worker process) and for configuration the default config file was used. The only change in the config was to enable dialog support.

to:

OpenSIPS was running in no fork mode (only one worker process) and for configuration the default config file was used. The only change in the config was to enable dialog support (via create_dialog() for initial INVITEs).

Changed lines 18-19 from:

Results

to:

Results

Changed lines 25-32 from:

time spent in memory ops - alloc + free (MEM)

to:

time spent in memory ops - alloc + free (MEM)

Conclusions

If you look from only the CPU usage perspective, you can see that managing the SIP messages (parsing and building) takes more than 50% of the CPU usage for OpenSIPS.

This information is actually useful for both developers and script writers to understand what is the impact of the functions they implement or use - abusing functions that do trigger parsing or not repeating the same parsing ops several times in different parts of the script.

October 08, 2009, at 04:44 PM by iulia_bublea -

Changed lines 11-12 from:

The results of the test are available either in a text format or displayed in the chart bellow, http://www.opensips.org/uploads/Resources/exec_time.gif which contains the overall results for memory (MEM), build (BUILD), parse (PARSE) and execution (EXEC) functions.

to:

The detailed results of the test are available either in a text format or displayed in the chart bellow, http://www.opensips.org/uploads/Resources/exec_time.gif which contains the overall results for the following groups:

time spent in parsing SIP messages (PARSE)
time spent in building SIP messages (BUILD)
time spent in generic execution, like script logic or network ops (EXEC)
time spent in memory ops - alloc + free (MEM)

October 08, 2009, at 04:39 PM by iulia_bublea -

Changed lines 5-6 from:

The profiling process was implemented on OpenSIPS proxy as an intermediary between a SIPp server and a SIPp client. OpenSIPS was compiled only with dialog support, and the server was started with one process.

to:

The profiling was done having OpenSIPS proxy as an intermediary between a SIPp server and a SIPp client (using standard UAC-UAS scenarios). OpenSIPS was running in no fork mode (only one worker process) and for configuration the default config file was used. The only change in the config was to enable dialog support.

October 08, 2009, at 04:33 PM by iulia_bublea -

Changed line 5 from:

The profiling process was implemented on OpenSIPS proxy as an intermediary between a SIPp server and a SIPp client.

to:

The profiling process was implemented on OpenSIPS proxy as an intermediary between a SIPp server and a SIPp client.

October 08, 2009, at 04:30 PM by iulia_bublea -

Changed lines 7-8 from:

Profiling was done with the gprof profiling tool for 10 million calls with a rate of 2000 simultaneous calls.

to:

Profiling was done with the gprof profiling tool for 10 million calls with a rate of 2000 simultaneous calls.

Changed lines 11-12 from:

The results of the test can available either in a text format or displayed in the chart bellow, http://www.opensips.org/uploads/Resources/exec_time.gif which contains the overall results for memory (MEM), build (BUILD), parse (PARSE) and execution (EXEC) procedures.

to:

The results of the test are available either in a text format or displayed in the chart bellow, http://www.opensips.org/uploads/Resources/exec_time.gif which contains the overall results for memory (MEM), build (BUILD), parse (PARSE) and execution (EXEC) functions.

October 08, 2009, at 04:25 PM by iulia_bublea -

Changed lines 11-12 from:

The results of the test can available either in a text format or displayed in the chart bellow, http://www.opensips.org/uploads/Resources/exec_time.gif which contains the overall results for memory (MEM), build (BUILD), parse (PARSE) and execution (EXEC) procedures.

to:

The results of the test can available either in a text format or displayed in the chart bellow, http://www.opensips.org/uploads/Resources/exec_time.gif which contains the overall results for memory (MEM), build (BUILD), parse (PARSE) and execution (EXEC) procedures.

October 08, 2009, at 04:25 PM by iulia_bublea -

Changed line 11 from:

The results of the test can be viewed by following this link: http://opensips.org/pub/tests/dialogprof or by viewing the charts containing overall results for memory (MEM), build (BUILD), parse (PARSE) and execution (EXEC) procedures. http://www.opensips.org/uploads/Resources/exec_time.gif

to:

The results of the test can available either in a text format or displayed in the chart bellow, http://www.opensips.org/uploads/Resources/exec_time.gif which contains the overall results for memory (MEM), build (BUILD), parse (PARSE) and execution (EXEC) procedures.

October 08, 2009, at 04:21 PM by iulia_bublea -

Changed lines 11-12 from:

The results of the test can be viewed by following this link: http://opensips.org/pub/tests/dialogprof or by viewing the charts containing overall results for memory (MEM), build (BUILD), parse (PARSE) and execution (EXEC) procedures.