About

About.PerformanceTests-InsertBuffering History

Show minor edits - Show changes to markup

May 14, 2013, at 02:19 PM by 109.99.235.212 -
Changed line 1 from:

About -> Performance Tests -> Insert buffering performance

to:
About -> Performance Tests -> Insert buffering performance
May 09, 2013, at 11:57 AM by 109.99.235.212 -
Changed line 1 from:

About -> Performance Tests -> Insert buffering performance

to:

About -> Performance Tests -> Insert buffering performance

May 09, 2013, at 11:56 AM by 109.99.235.212 -
Changed line 8 from:

As we have seen from previous performance tests, database operations are very costly, and have a serious impact on the performance of the proxy, so, whenever possible, we should try to decrease the number of DB queries that OpenSIPS has to do.

to:

As we have seen from previous performance tests, database operations are very costly, and have a serious impact on the performance of the proxy, so, whenever possible, we should try to decrease the number of DB queries that OpenSIPS has to do.

April 24, 2013, at 01:05 PM by 109.99.235.212 -
Changed line 1 from:

Resources -> Performance Tests -> Insert buffering performance

to:

About -> Performance Tests -> Insert buffering performance

April 24, 2013, at 12:58 PM by 109.99.235.212 -
Added lines 1-64:

Resources -> Performance Tests -> Insert buffering performance

This page has been visited 8792 times. (:toc-float Table of Content:)


There are quite a few OpenSIPS modules that need to store information in the database ( acc, siptrace, etc ), or that need to synchronize information with the DB from time to time, so in case of a failure, the info can be retrieved from the database ( dialog, usrloc, etc ).

As we have seen from previous performance tests, database operations are very costly, and have a serious impact on the performance of the proxy, so, whenever possible, we should try to decrease the number of DB queries that OpenSIPS has to do.


What was the used approach ?

Instead of flushing inserted rows one by one into the database, OpenSIPS will now store rows in memory, and only flush them to DB when a certain number of rows have piled up in memory. The flushing of the rows will be done within a single SQL command.

Two new parameters have been added to the OpenSIPS core :

query_buffer_size - number of rows that will be flushed at once to the database.
query_flush_time - if a query is being held in memory longer that this number of seconds, it will be forcefully flushed to the database by a timer. This is done to preserve real-time synchronization with the DB.

What are the theoretical gains ?

With fewer database operations, we should gain the following

  • a better response time from the proxy
  • less load overall on the server ( OpenSIPS and mysql daemon )
  • ultimately, a higher number of CPS that can be handled by the proxy

Performance test

The tests were done using OpenSIPS 1.6.4 as reference point. OpenSIPS 1.7.0 (devel) is the candidate whose performance was measured.

The test were performed with a simple script scenario, where the proxy would only do accounting ( old type of accounting, not CDR ). The database back-end used was MYSQL, and the database server was located on a different machine than the main proxy, but in the same LAN.


Results

1. On a constant rate of 1500 CPS pushed through the proxy, the load on the mysql daemon was :

  • OpenSIPS 1.6.4 : 71.5 %
  • OpenSIPS 1.7.0 : 35.1 %

-> BOOST = ~50 % lower load on mysql

2. In terms of raw CPS, the maximum number of calls per second that the proxy could handle was :

  • OpenSIPS 1.6.4 : 1700 CPS
  • OpenSIPS 1.7.0 : 3000 CPS

-> BOOST = ~75 % higher CPS

3. In terms of wait time on the OpenSIPS server, with a total of 10 SIP listening children, the average number of children sleeping, waiting for an event was :

  • OpenSIPS 1.6.4 : 8.6 children sleeping at any given time
  • OpenSIPS 1.7.0 : 7.2 children sleeping at any given time

Conclusions

The new insert buffering feature introduced in OpenSIPS 1.7 offers great advantages, because you eventually end up with less DB queries done by the proxy, which translates into more time to handle the SIP related work.


Page last modified on May 14, 2013, at 02:19 PM