I would like to comment on my own post, unlike signate before in 2006 , according to their pdf they did do their homework and used a setting new to sipp: :make pcapplay”instead of the echo mode. which should fix that, and reinvite is set to no, so i cannot find any flaws in the test setup, however i would still like to see pps measurements, i still can't believe linux can handle that amount of packets per second in userlevel on that type of hardware. (based on my own measurements from years ago on a dual xeon - not dual core)
Zoa Zoa wrote: > When doing the packets, can you also monitor the bandwitdh used ? As i > pointed out before, SIPp does not generate audio and asterisk will not > send audio packets unless packets are received. > (This does conflict with the fact that you see higher load when > transcoding is used). > > 400 transcodings is about what i would expect for the cpu's, but the > 1500 simultaneous calls is more then i would expect from linux user land > packet handling on that system. > Did you do any tweaks with the kernel or cpu affinity for this ? What > network card are you using ? On top load, how much is going to system ? > What kernel are you using ? > > Zoa > > Matthew Rubenstein wrote: > >> I see from your webpage report that you used SIPp clients to generate >> the call legs. >> >> >> On Fri, 2007-11-16 at 15:56 -0500, Matthew Rubenstein wrote: >> >> >>> That is extremely valuable baseline data. >>> >>> What did you use to generate the test call legs? Would you consider >>> rerunning the tests, throwing all the call legs into MeetMe conferences >>> (2 or 4 way) instead of simple call completion, to benchmark >>> conferencing's capacity requirements vs the baseline? With that info, >>> most of the feature capacity requirements can be derived to a >>> per-feature, per-leg basis for capacity planning. Only audio recording >>> would be left as a major feature, but that's not as common. >>> >>> >>> On Fri, 2007-11-16 at 15:41 -0500, Jim Dalton wrote: >>> >>> >>>> SIP >>>> >>>> Jim Dalton >>>> VoIP Routing, Accounting, Security >>>> 1.404.526.6053 >>>> www.TransNexus.com >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Matthew Rubenstein [mailto:[EMAIL PROTECTED] >>>>> Sent: Friday, November 16, 2007 3:35 PM >>>>> To: Jim Dalton >>>>> Cc: Asterisk -Biz >>>>> Subject: RE: [asterisk-biz] Asterisk Performance Results >>>>> >>>>> SIP, ZAP or ? >>>>> >>>>> >>>>> On Fri, 2007-11-16 at 15:34 -0500, Jim Dalton wrote: >>>>> >>>>> >>>>>> Each call has two legs: one call leg inbound to the B2BUA >>>>>> >>>>>> >>>>> and one call >>>>> >>>>> >>>>>> leg outbound from the B2BUA. >>>>>> >>>>>> 1500/400 calls >>>>>> 3000/800 call legs >>>>>> >>>>>> Jim Dalton >>>>>> VoIP Routing, Accounting, Security >>>>>> 1.404.526.6053 >>>>>> www.TransNexus.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: [EMAIL PROTECTED] >>>>>>> [mailto:[EMAIL PROTECTED] On Behalf >>>>>>> >>>>>>> >>>>> Of Matthew >>>>> >>>>> >>>>>>> Rubenstein >>>>>>> Sent: Friday, November 16, 2007 3:10 PM >>>>>>> To: Jim Dalton >>>>>>> Cc: Asterisk -Biz >>>>>>> Subject: Re: [asterisk-biz] Asterisk Performance Results >>>>>>> >>>>>>> Thanks for the data. Are those 1500/400 calls 2-leg calls, or >>>>>>> individual legs of calls (so really 750/200 2-leg calls)? >>>>>>> >>>>>>> >>>>>>> On Fri, 2007-11-16 at 15:02 -0500, Jim Dalton wrote: >>>>>>> >>>>>>> >>>>>>>> We recently performed an indepth performance test on >>>>>>>> >>>>>>>> >>>>>>> Asterisk V1.4.11 >>>>>>> >>>>>>> >>>>>>>> configured as a SIP B2BUA. >>>>>>>> >>>>>>>> Asterisk was running on a server with two Xeon 5140, dual >>>>>>>> >>>>>>>> >>>>>>> core, 2.33 >>>>>>> >>>>>>> >>>>>>>> GHz CPUs and 4 GB of RAM. >>>>>>>> >>>>>>>> We found that an Asterisk B2BUA on this hardware can >>>>>>>> >>>>>>>> >>>>> manage 1500 >>>>> >>>>> >>>>>>>> simultaneous calls with no transcoding and 400 simultaneous >>>>>>>> >>>>>>>> >>>>>>> calls with >>>>>>> >>>>>>> >>>>>>>> G.711 to G.729 transcoding. >>>>>>>> >>>>>>>> A summary of the test is available at >>>>>>>> >>>>>>>> >>>>>>>> >>>>> http://www.transnexus.com/White%20Papers/asterisk_V1-4-11_performance. >>>>> >>>>> >>>>>>>> htm >>>>>>>> The test details are available at >>>>>>>> >>>>>>>> >>>>>>>> >>>>> http://www.transnexus.com/White%20Papers/Asterisk_Performance_as_a_S >>>>> >>>>> >>>>>>> IP >>>>>>> >>>>>>> >>>>>>>> _B2BUA >>>>>>>> .pdf >>>>>>>> >>>>>>>> Jim Dalton >>>>>>>> www.transnexus.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> --Bandwidth and Colocation Provided by >>>>>>>> http://www.api-digital.com-- >>>>>>>> >>>>>>>> asterisk-biz mailing list >>>>>>>> To UNSUBSCRIBE or update options visit: >>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-biz >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> >>>>>>> (C) Matthew Rubenstein >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> --Bandwidth and Colocation Provided by >>>>>>> >>>>>>> >>>>> http://www.api-digital.com-- >>>>> >>>>> >>>>>>> asterisk-biz mailing list >>>>>>> To UNSUBSCRIBE or update options visit: >>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-biz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>> >>>>> (C) Matthew Rubenstein >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> > > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-biz mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-biz > _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz
