From openSIPS

About: PerformanceTests-InsertBuffering

About -> Performance Tests -> Insert buffering performance

This page has been visited 7430 times.

Table of Content (hide)

  1. 1. What was the used approach ?
  2. 2. What are the theoretical gains ?
  3. 3. Performance test
  4. 4. Results
  5. 5. Conclusions

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.

1.  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.

2.  What are the theoretical gains ?

With fewer database operations, we should gain the following

3.  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.

4.  Results

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

-> 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 :

-> 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 :

5.  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.

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