1 / 16

Measurement and Evaluation of ENUM Server Performance

Measurement and Evaluation of ENUM Server Performance. Charles Shen and Henning Schulzrinne Dept. of Computer Science, Columbia University, New York, NY. Motivation. ENUM translates E.164 No. to URIs Built upon DNS infrastructure Query response time

sen
Download Presentation

Measurement and Evaluation of ENUM Server Performance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Measurement and Evaluation of ENUM Server Performance Charles Shen and Henning Schulzrinne Dept. of Computer Science, Columbia University, New York, NY ICC 2007

  2. Motivation • ENUM translates E.164 No. to URIs • Built upon DNS infrastructure • Query response time • PSTN post-dial delay in the order of seconds • PSTN switch processing time in the order of 200 to 350 ms • Query throughput, database size, bulk record update • E.g. 100 million users , 0.1 erlang traffic • over 100 million records • 50,000 calls per second during busy hour • Can existing DNS servers be used for ENUM? • no comprehensive study found at the time ICC 2007

  3. ENUM in a Nutshell 1-212-939-1234 Input an E.164 number 4.3.2.1.9.3.9.2.1.2.1.e164.arpa Transform to FQDN IN NAPTR 0 0 "u" "E2U+sip" \ "!ˆ.*$!sip:info@enum.example.com Look for NAPTR record Apply regexs to get the result sip:info@enum.example.com ICC 2007

  4. Name Server Software Evaluated ICC 2007

  5. ENUMperf Test-bed ICC 2007

  6. PDNS Throughput For existing records • Peak throughput at around 5,500 q/s • Peak throughput of querying non-existent records is only 630 q/s (almost 1/9!) ICC 2007

  7. PDNS Response Time For existing records • Value in the range of one millisecond • Database lookup time contributes more than 60% • Querying non-existent records dominated by Start Of Authority (SOA) searches ICC 2007

  8. PDNS Database Scaling For existing records • Good when records are in memory • Poor otherwise • Similar when querying non-existent records • but with much lower peak throughput ICC 2007

  9. PDNS - Impact of Cache For existing records • Implementation flaw in cache cleanup made performance worse than no cache when cache size is large • all results shown assume it is fixed • Throughput increases 100% (packet cache) or 50% (query cache) • Close to an order of magnitude increase for querying non-existent records with query cache ICC 2007

  10. Comparing Throughput - Existing Records For existing records • Navitas peak throughput more than three times that of PDNS • BIND not included (only 1/50 of Navitas’) ICC 2007

  11. Comparing Throughput -- Non-Existing Records For non-existing records • Navitas about 10 times of PDNS and 6 times of BIND • BIND outperforms PDNS • PDNS inefficient for non-existing records ICC 2007

  12. Comparing Response Time For non-existent records • Within one millisecond for all three • Considered well below the call signaling budget • Similar for existing records ICC 2007

  13. Database Scaling - BIND • Poor for existing records • Good for non-existent records (better than PDNS) • Degrade dramatically with out-of-memory records ICC 2007

  14. Database Scaling - Navitas • Best scaling property among the three • Out of memory records not tested ICC 2007

  15. Background Update Load Impact • PDNS peak query throughput drops by 20% • Navitas peak query throughput largely unaffected, but fluctuation is seen • Response time variation at sub-milliseconds ICC 2007

  16. Conclusions • Query response time not a concern for post-dial delay • BIND poor: scaling and background update • PDNS and Navitas suitable for ENUM • Navitas significantly better due to optimization for ENUM • PDNS can be improved to better serve ENUM • cache maintenance • ENUM records memory efficiency • fast-path handling of non-existing records ICC 2007

More Related