Fwd: Problem when load testing Asterisk 13.7.2

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

 




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

[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