Re: Fwd: Problem when load testing Asterisk 13.7.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sean,

I think I understood your comment incorrectly, let me try this again. I did try a PJSIP based testing framework a while ago. I could not get it to work, and I have forgotten what it was.

Anyway, what I think you are saying is that if I have come this far, why not write the entire testing framework using PJSIP (and Python, maybe) as it can get quite simple if I use the high level PJSUA binding.

I have not tried that. And at this time, it is worth a look, especially because I find SIPp very cumbersome.

So, thanks!

On Sun, Mar 20, 2016 at 10:47 PM, Sean Brady <sbrady@xxxxxxxxxxxxxxxxxxxx> wrote:
Works fine for me, and it compiles with PJSIP. 

On Mar 20, 2016, at 20:46, Tickling Contest <tickling.contest@xxxxxxxxx> wrote:

Sorry, but I started with PJSUA and was told that the package is broken. I couldn't get it work. Thanks, though.

On Sun, Mar 20, 2016 at 10:43 PM, Sean Brady <sbrady@xxxxxxxxxxxxxxxxxxxx> wrote:
You can also use pjsua if you're looking for something simpler. If you know Python there are bindings for it as well. Freeswitch is incredibly suited to what I believe is your use case. 

HTH 

On Mar 20, 2016, at 20:39, Tickling Contest <tickling.contest@xxxxxxxxx> wrote:

Thanks George, I think I am very, very, very confused with sipp and how it handles the coordination (I thought I knew this well, but the pause and ti. There _HAS_ to be a simpler way. It is just way. Too. Complex. I just surprised that there isn't a better tool for something that has a load  of use. Maybe I should move to Asterisk based testing. Known beast...

I have already gotten it working for a single call; you will recall in my OP I wasn't able to push it beyond about a 100 calls concurrently, and that's when I decided to let sipp manage everything.

The sipp software, I think is also quite buggy.

For example, I know that -p flag is supposed to take the port over which the peer registers. This port shows up when you do pjsip show endpoint <peerExtension>. I know this (i.e., -p param)  works in my sipp because that's how I controlled each peer in my earlier sipp load test scenario.

Well, now, the local_port does not work when I pass it as a CSV file and modify the [local_port] to [field0] etc, and as a result, the calls are not going through.

They also don't have the updated documentation for release 3.5.1 which is what I am using. Sigh!

On Sun, Mar 20, 2016 at 9:12 PM, George Joseph <george.joseph@xxxxxxxxxxxxx> wrote:

Oh, BTW...

If sipp doesn't do it for you, there's another great tool you can use for load testing.  It's called Asterisk. :)

For more complex scenarios, what I've done in the past is set up 3 Asterisk instances, 1 as the call generator, 1 as the system under test, and 1 as the call receiver.

On the generator instance, I have a script that keeps enough call files in /var/spool/asterisk/outgoing to simulate the number of calls I want.  On the call receiver, I can set up the dialplan to do anything I want with the calls.  Transfer, play something, echo, park.  Whatever.


On Sun, Mar 20, 2016 at 6:37 PM, George Joseph <george.joseph@xxxxxxxxxxxxx> wrote:


On Sun, Mar 20, 2016 at 5:29 PM, Tickling Contest <tickling.contest@xxxxxxxxx> wrote:
OK. I did that, but now, all I do is get into an infinite loop with the registrations at the callee. Here's the gist: https://gist.github.com/ticklingcontest/a0754549a88dc748f52d

Ideally, here's what I need:

callee registers, and accepts an infinite number of calls.
caller registers, and then sends INVITES an infinite number of times so as to keep the total number of calls per the (-l parameter).

It is not clear to me how I would loop at the callee scenario or caller scenario.

​You don't loop anything.  sipp runs the scenarios itself repeatedly until​ -m calls have been processed.

I'd start without your script or the csv files and just get a simple 1 call scenario to work.

If you want some good examples, look at the Asterisk testsuite tests/channels/pjsip/basic_calls scenarios.

Here's a caller file I used often...  

register
pause 1 sec
invite
pause 1 sec
bye
pause 1 sec
unregister

To simulate a call from a phone with extension/endpoint name 1100, run it like so...
# sipp -sf reg_and_call.xml -s 1100 -au 1100 -ap <password> -m 1 <server:ip>

If you want it to resister/call/unregister 100 times with 10 parallel calls over TCP, run 

# sipp -sf reg_and_call.xml -t tn -s 1100 -au 1100 -ap <password> -m 100 -l 10  <server_ip:port>

Once you get that working by itself to an existing extension,  set up your callee the same way, then call it from a normal working extension and make sure it responds correctly.

Then have your caller call the callee, first as a single call, then try multiple calls.

Only when you have that working should you  introduce your injection files.


What is really confusing in the caller script apart from the real confusion I have with -m and -l parameters, is how the caller's INVITE goes out from the same port as the registered port especially when they are called as two separate processes. Does sipp write a  dot file somewhere where it gets its information from?

​Nope.​


BTW, In this model, I pass the CSV file that is pre-generated for the calls using a python script that looks like this:

SEQUENTIAL
callerID1;AsteriskIPAddress;[authentication username=silly password=sillier];calleeID1;callDuration1;
callerID2;AsteriskIPAddress;[authentication username=silly password=sillier];calleeID2;callDuration2;
...
callerIDn;AsteriskIPAddress;[authentication username=silly password=sillier];calleeIDn;callDurationn;
etc.

Again, any help is appreciated. I can see how this is turning into a sipp tutorial, so I understand if you have issues dealing with this here, but I can tell that SIPp help is very sparing online.

Thanks!

​I'll say again...  If you want some good examples, look at the Asterisk testsuite tests/channels/pjsip/basic_calls scenarios.  There are both inbound and outbound scenarios, authed and unauthed.


_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev


_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev


_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev


_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux