Resources.TestsUsrloc History

Show minor edits - Show changes to markup

April 24, 2013, at 02:34 PM by 109.99.235.212 -
Changed lines 1-56 from:

Resources -> Performance Tests -> User location - search performance

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

User locations are in general stored in memory for faster searches. Up to OpenSIPS 1.6.0 they were held in a hash-table for faster searching. The trunk (OpenSIPS 1.7.0 (devel)) contains a new version that combines the use of hash-tables and balanced search trees.

The tests were conducted in order to determine the real gain of the balanced search trees in cases with many registered users.

What are the theoretical gains ?

Hash-tables supply a constant query time as long as they are not loaded too much. After a certain limit search time rises linear with the number of registered users. Balanced search trees are used to prevent this from happening.

Performance tests

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

Search performance tests

The test was performed with a constant number of 100.000 registered users. Queries were done for users registered at different times ( in the original implementation query time was dependant on how close a user was to the begining of the list).

http://www.opensips.org/uploads/Resources/general_comparison.jpg | General view

Results:

  • old implementation (OpenSIPS 1.6.0) = 13 micro secs (avg per query)
  • new implementation (OpenSIPS 1.7.0) = 4 micro secs (avg per query)

-> BOOST = 3.25 times faster

http://www.opensips.org/uploads/Resources/single_sample.jpg | Single Sample (detail)

Conclusions

  • There was an increase of 325% in speed for a test with 100.000 users. For a system with a larger number of users this would increase.
  • Query time is now constant in the size of the registered users pool.
  • For a small system with just a few thousand users the gain would not be noticeable.


to:

(:redirect About.PerformanceTests-UserLocation quiet=1:)

Restore
February 11, 2010, at 02:37 PM by bogdan -
Changed line 41 from:

http://www.opensips.org/uploads/Resources/single_sample.jpg | Single Sample (detail)

to:

http://www.opensips.org/uploads/Resources/single_sample.jpg | Single Sample (detail)

Restore
February 11, 2010, at 02:36 PM by bogdan -
Changed line 41 from:

http://www.opensips.org/uploads/Resources/single_sample.jpg | Single Sample (detail)

to:

http://www.opensips.org/uploads/Resources/single_sample.jpg | Single Sample (detail)

Restore
November 13, 2009, at 04:50 PM by adragus -
Changed line 47 from:
  • There was a gain of 64% for a test with 100.000 users. For a system with a larger number of users this would increase.
to:
  • There was an increase of 325% in speed for a test with 100.000 users. For a system with a larger number of users this would increase.
Restore
November 13, 2009, at 04:47 PM by adragus -
Changed line 33 from:
  • old implementation (OpenSIPS 1.6.0) = 11 micro secs (avg per query)
to:
  • old implementation (OpenSIPS 1.6.0) = 13 micro secs (avg per query)
Changed line 38 from:

-> BOOST = 64 %

to:

-> BOOST = 3.25 times faster

Restore
November 04, 2009, at 06:19 PM by adragus -
Changed lines 6-7 from:

User locations are in general stored in memory for faster searches. Up to OpenSIPS 1.6.0 they were held in a hash-table for faster searching. The trunk contains a new version that combines the use of hash-tables and balanced search trees.

to:

User locations are in general stored in memory for faster searches. Up to OpenSIPS 1.6.0 they were held in a hash-table for faster searching. The trunk (OpenSIPS 1.7.0 (devel)) contains a new version that combines the use of hash-tables and balanced search trees.

Changed line 15 from:

Hash-tables supply a constant query time as long as they are not loaded to much. After a certain limit search time rises linear with the number of registered users. Balanced search trees are used to prevent this from happening.

to:

Hash-tables supply a constant query time as long as they are not loaded too much. After a certain limit search time rises linear with the number of registered users. Balanced search trees are used to prevent this from happening.

Restore
November 04, 2009, at 06:15 PM by adragus -
Restore
November 04, 2009, at 06:15 PM by adragus -
Changed line 49 from:
  • Query time is now constant in the size of the registered users.
to:
  • Query time is now constant in the size of the registered users pool.
Restore
November 04, 2009, at 06:14 PM by adragus -
Changed line 30 from:

http://www.opensips.org/uploads/Resources/general_comparison.jpg | Chart 1

to:

http://www.opensips.org/uploads/Resources/general_comparison.jpg | General view

Changed lines 41-52 from:

http://www.opensips.org/uploads/Resources/single_sample.jpg | Chart 2

to:

http://www.opensips.org/uploads/Resources/single_sample.jpg | Single Sample (detail)

Conclusions

  • There was a gain of 64% for a test with 100.000 users. For a system with a larger number of users this would increase.
  • Query time is now constant in the size of the registered users.
  • For a small system with just a few thousand users the gain would not be noticeable.
Restore
November 04, 2009, at 06:09 PM by adragus -
Changed line 30 from:

http://www.opensips.org/uploads/Resources/general_comparison.jpg | Chart 1

to:

http://www.opensips.org/uploads/Resources/general_comparison.jpg | Chart 1

Changed line 41 from:

http://www.opensips.org/uploads/Resources/single_sample.jpg | Chart 2

to:

http://www.opensips.org/uploads/Resources/single_sample.jpg | Chart 2

Restore
November 04, 2009, at 06:08 PM by adragus -
Changed lines 33-36 from:
  • no prepared statements (OpenSIPS 1.4.4) = 254 micro secs (avg per query)
  • with prepared statements (OpenSIPS 1.5.0) = 202 micro secs (avg per query)
to:
  • old implementation (OpenSIPS 1.6.0) = 11 micro secs (avg per query)
  • new implementation (OpenSIPS 1.7.0) = 4 micro secs (avg per query)
Changed lines 38-43 from:

-> BOOST = 21 %

See full size chart

See OpenOffice SpreadSheet with all result values.

to:

-> BOOST = 64 %

Added lines 40-43:

http://www.opensips.org/uploads/Resources/single_sample.jpg | Chart 2

Restore
November 04, 2009, at 06:03 PM by adragus -
Changed lines 23-24 from:

Tests were performed with 100000 registered users.

to:
Changed lines 27-33 from:

This test (using auth_db module) was focus in measuring he gain of a simple query:

  • low complexity query (as simple select with 2 fields)
  • low volume of data pushed to mysql (2 short strings - username and domain)

Scenario: REGISTER requests, challenged and authenticated.

http://www.opensips.org/uploads/Resources/general_comparison.jpg | Chart 1

to:

The test was performed with a constant number of 100.000 registered users. Queries were done for users registered at different times ( in the original implementation query time was dependant on how close a user was to the begining of the list).

http://www.opensips.org/uploads/Resources/general_comparison.jpg | Chart 1

Restore
November 04, 2009, at 05:57 PM by adragus -
Changed line 45 from:

See full size chart

to:

See full size chart

Restore
November 04, 2009, at 05:56 PM by adragus -
Changed line 34 from:

http://www.opensips.org/uploads/Resources/stmt_auth_char.gif | Chart 1

to:

http://www.opensips.org/uploads/Resources/general_comparison.jpg | Chart 1

Restore
November 04, 2009, at 05:50 PM by adragus -
Changed line 26 from:

DB Authentication test

to:

Search performance tests

Restore
November 04, 2009, at 05:49 PM by adragus -
Deleted lines 50-103:

User location test

This test (using usrloc module) was focus in measuring he gain of more complex query:

  • highy complexity query (an insert with 13 fields and 2 "where" values)
  • low volume of data pushed to mysql (only short strings, integers, datatime values)

Scenario: REGISTER requests, no authentication,

http://www.opensips.org/uploads/Resources/stmt_usrloc_char.gif | Chart 2

Results:

  • no prepared statements (OpenSIPS 1.4.4) = 477 micro secs (avg per query)
  • with prepared statements (OpenSIPS 1.5.0) = 358 micro secs (avg per query)

-> BOOST = 25 %

See full size chart

See OpenOffice SpreadSheet with all result values.


SIPTrace test

This test (using siptrace module) was focus in measuring he gain of simple, but datafull query:

  • low complexity query (an insert with 6 fields)
  • large volume of data pushed to mysql (BLOBs containing a whole SIP message is inserted)

Scenario: REGISTER requests, no authentication,

http://www.opensips.org/uploads/Resources/stmt_siptrace_char.gif | Chart 3

Results:

  • no prepared statements (OpenSIPS 1.4.4) = 556 micro secs (avg per query)
  • with prepared statements (OpenSIPS 1.5.0) = 428 micro secs (avg per query)

-> BOOST = 23 %

See full size chart

See OpenOffice SpreadSheet with all result values.


Restore
November 04, 2009, at 05:47 PM by adragus -
Added lines 1-104:

Resources -> Performance Tests -> User location - search performance

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

User locations are in general stored in memory for faster searches. Up to OpenSIPS 1.6.0 they were held in a hash-table for faster searching. The trunk contains a new version that combines the use of hash-tables and balanced search trees.

The tests were conducted in order to determine the real gain of the balanced search trees in cases with many registered users.

What are the theoretical gains ?

Hash-tables supply a constant query time as long as they are not loaded to much. After a certain limit search time rises linear with the number of registered users. Balanced search trees are used to prevent this from happening.

Performance tests

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

Tests were performed with 100000 registered users.

DB Authentication test

This test (using auth_db module) was focus in measuring he gain of a simple query:

  • low complexity query (as simple select with 2 fields)
  • low volume of data pushed to mysql (2 short strings - username and domain)

Scenario: REGISTER requests, challenged and authenticated.

http://www.opensips.org/uploads/Resources/stmt_auth_char.gif | Chart 1

Results:

  • no prepared statements (OpenSIPS 1.4.4) = 254 micro secs (avg per query)
  • with prepared statements (OpenSIPS 1.5.0) = 202 micro secs (avg per query)

-> BOOST = 21 %

See full size chart

See OpenOffice SpreadSheet with all result values.


User location test

This test (using usrloc module) was focus in measuring he gain of more complex query:

  • highy complexity query (an insert with 13 fields and 2 "where" values)
  • low volume of data pushed to mysql (only short strings, integers, datatime values)

Scenario: REGISTER requests, no authentication,

http://www.opensips.org/uploads/Resources/stmt_usrloc_char.gif | Chart 2

Results:

  • no prepared statements (OpenSIPS 1.4.4) = 477 micro secs (avg per query)
  • with prepared statements (OpenSIPS 1.5.0) = 358 micro secs (avg per query)

-> BOOST = 25 %

See full size chart

See OpenOffice SpreadSheet with all result values.


SIPTrace test

This test (using siptrace module) was focus in measuring he gain of simple, but datafull query:

  • low complexity query (an insert with 6 fields)
  • large volume of data pushed to mysql (BLOBs containing a whole SIP message is inserted)

Scenario: REGISTER requests, no authentication,

http://www.opensips.org/uploads/Resources/stmt_siptrace_char.gif | Chart 3

Results:

  • no prepared statements (OpenSIPS 1.4.4) = 556 micro secs (avg per query)
  • with prepared statements (OpenSIPS 1.5.0) = 428 micro secs (avg per query)

-> BOOST = 23 %

See full size chart

See OpenOffice SpreadSheet with all result values.


Restore
Edit | History | Print | Recent Changes | Search
Page last modified on April 24, 2013, at 02:34 PM