Scott Lawrence wrote: > Let's make a note to try to set up a large scale (at least > 100's of NATed UAs) test to see if there's an important difference.
I implemented the shortened registration times for NAT traversal on my working copy and proceeded to measure the performance impact of the change. For non-NATed phones, the registration expiry range remains 300 to 7200 seconds and for NATed phones, I use a much reduced range of 180 to 300 seconds. I did my performance measurements on a Dell OptiPlex 745 equipped with an Intel Core 2 Duo @ 2GHz. All performance measurements were done using custom SIPp scripts simulating 1000 registrants and CPU utilization measurements were averaged over a 10 minute period starting 5 minutes after the beginning of the test using the 'sar' utility. Performance Measurement #1 ========================== 1000 Non-NATed registrants requesting an Expiry or 3600 seconds and refreshing half-way through expiry SipXproxy Average CPU Util (%user %system): 0.47 0.03 SipXproxy Average CPU Util (%user %system): 0.79 0.03 Total: 1.32% of one CPU Performance Measurement #2 ========================== 1000 NATed registrants requesting an Expiry or 3600 seconds and refreshing half-way through expiry SipXproxy Average CPU Util (%user %system): 5.29 0.42 SipXproxy Average CPU Util (%user %system): 3.41 0.17 Total: 9.29% of one CPU Performance Measurement #3 ========================== 1000 NATed registrants requesting an Expiry or 3600 seconds and refreshing 30 seconds before expiry SipXproxy Average CPU Util (%user %system): 3.15 0.23 SipXproxy Average CPU Util (%user %system): 2.74 0.11 Total: 6.23% of one CPU My Conclusions: The performance measurements were done using an aggressive remote user count of 1000 and was conducted on a very moderately-powered server model and even in these conditions, the registration process did not consume more than 10% of one CPU of the multi-core system (9.29% in the worst case and 6.23% in the best). Given these results and the fact that the registration expiry intervals for NATed and non-NATed users will be configurable via the registrar-config file, I conclude it is safe, from a performance POV, to introduce this feature. Anybody disagrees? 8< _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
