>> 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? >> >> >Dave Deutschman wrote: > >How did it affect bandwidth consumption? I think that will be as important >as the Internet circuit the remote workers use to access sipXecs may be >limited in bandwidth. Good question. This change increases the network bandwidth required for registrations by a factor of about 8 but still amounts to fairly modest numbers. To give you an order of magnitude, maintaining 1000 remote worker registrations whereby they re-register 30 seconds before expiry chewed up a total of 11Kb/s (4.8Kb/s downlink and 6.2Kb/s uplink). Do these numbers appear reasonable to you? _______________________________________________ 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/
