Hi again and thanks,
now I do have a better idea of what is happening,
in my cryptic :) sentence actually was referring to your example
sipp -sf your_scenario_name.xml -r 100 -rp 80 -l 1000 -m 2000
and my question was if the calls made (and I thought calls you mean audio calls
:) )
creates a sip session that lasts some time, and was suspecting it lasts until
the last call is made, that is when the maximum limit of 2000 is reached.
But actually there is no session at all right? When 200 ok comes back, or
whatever else, that's it.
It must have been the SIP name (session initiation protocol) that made me think
there will be a session, and so I didn't see where is the life of it set :)
Anyway indeed is tricky then to test a large number of people using the
FreeSwitch, maybe the best test is like simultaneous calls , using the -r flag
(at least this one works here :) ).
Cheers,Adrian
-----------------------------------------------------------------------------------------
Take the power back!
On Monday, 21 March 2016, 17:18, sindelka <sinde...@ttc.cz> wrote:
Hi Adi,
in sipp, a "call" is a single pass through the from start to end, regardless
whether it is an actual call-controlling (INVITE-200-BYE-200) dialog, a
REGISTER-401-REGISTER-200 sequence, or e.g. a SUBSCRIBE-200-NOTIFY-200-...
dialog.
So in your register_client.xml, the "call" ends by receiving the 200 response
to the Register with authentication header.
The number of balls in the air is determined by total flight time of a single
ball (in your case, Σt = twice the network round-trip time plus Kamailio's
processing time of non-authenticated and of authenticated REGISTER) and the
number of balls you manage to throw until the first one falls back. If the
Kamailio is quick enough and the network path is short enough, you may actually
get just tens of really concurrent calls for 100 calls in 80 ms. So I'd
recommend to track the time of the first REGISTER and of the 200 response to
the 2nd one (either using the sipp logging facility or using tcpdump/Wireshark)
and modify -r and -rp depending on the result (like -r 1000 -rp Σt).
Also think about the time it takes to send a message through a network
interface of a given bitrate: a 1250-byte message represents about 10000 bits
to be sent, so on a 100 Mbit/s Ethernet, you cannot send more than 10 such
messages per millisecond, i.e. 800 in 80 milliseconds, if there is no other
traffic on the interface.
If you say that -r X -rp Y -l Z -m T doesn't do anything, try to add the
parameters one-by-one, left-to-right, to find out which one breaks it, and then
start omitting them one by one (-r -rp, -r -rp -l, -r -rp -l -m, -r -l -m, ...)
to see if some combinations are not a problem, rather than individual
parameters.
This sentence is totally cryptic to me, it seems you were in a hurry:
Also is this test to "create 100 calls during each 80 milliseconds up to a
limit of 1000 calls in progress" means that the calls, here register method
calls not ths calls calls,
are keep-alive simultaneous till the 2000 one ends?
If what I wrote is not the answer, please translate the sentence.
P.
Dne 21.3.2016 v 16:00 adrian Albu napsal(a):
Díky Sindelka,
./sipp -sf register_client.xml -inf user21.csv -i local_ip kamailio_ip:k_port
-trace_err -r 100
is kind of working using
<?xml version="1.0" encoding="ISO-8859-1" ?> <scenario
name="register_client"> <send retrans="500"> <![CDATA[ REGISTER
sip:[remote_ip] SIP/2.0 Via: SIP/2.0/[transport]
[local_ip]:[local_port];branch=[branch] From:
<sip:[field0]@[field1]>;tag=[call_number] To: <sip:[field0]@[field1]> Call-ID:
[call_id] CSeq: 1 REGISTER Contact: sip:[field0]@[local_ip]:[local_port]
Max-Forwards: 5 Expires: 1800 User-Agent: SIPp/Linux Content-Length: 0 ]]>
</send> <recv response="401" auth="true"> </recv> <send retrans="500">
<![CDATA[ REGISTER sip:[remote_ip] SIP/2.0 Via: SIP/2.0/[transport]
[local_ip]:[local_port];branch=[branch] From:
<sip:[field0]@[field1]>;tag=[call_number] To: <sip:[field0]@[field1]> Call-ID:
[call_id] CSeq: 2 REGISTER Contact: sip:[field0]@[local_ip]:[local_port]
[field2] Max-Forwards: 5 Expires: 1800 User-Agent: SIPp/Linux Content-Length: 0
]]> </send> <recv response="200"> </recv> </scenario>
here is the result:
------------------------------ Scenario Screen -------- [1-9]: Change Screen
-- Call-rate(length) Port Total-time Total-calls Remote-host 100.0(0
ms)/1.000s 5060 20.05 s 2005 kamailio_ip:k_port(UDP)
2 new calls during 0.021 s period 1 ms scheduler resolution 1 calls
(limit 300) Peak was 1 calls, after 0 s 0 Running, 2008
Paused, 2 Woken up 0 dead call msg (discarded) 0 out-of-call msg
(discarded) 3 open sockets
Messages Retrans Timeout Unexpected-Msg
REGISTER ----------> 2005 0 0 401 <----------
2005 0 0 0 REGISTER ----------> 2005
0 0 200 <---------- 2004 0 0 0
------------------------------ Test Terminated --------------------------------
----------------------------- Statistics Screen ------- [1-9]: Change Screen
-- Start Time | 2016-03-21 15:50:31.598871 1458571831.598871
Last Reset Time | 2016-03-21 15:50:51.632419 1458571851.632419
Current Time | 2016-03-21 15:50:51.654458 1458571851.654458
-------------------------+---------------------------+--------------------------
Counter Name | Periodic value | Cumulative value
-------------------------+---------------------------+--------------------------
Elapsed Time | 00:00:00:022000 | 00:00:20:055000 Call
Rate | 90.909 cps | 99.975 cps
-------------------------+---------------------------+--------------------------
Incoming call created | 0 | 0 OutGoing
call created | 2 | 2005 Total Call created |
| 2005 Current Call | 1
|
-------------------------+---------------------------+--------------------------
Successful call | 2 | 2004 Failed call
| 0 | 0
-------------------------+---------------------------+--------------------------
Call Length | 00:00:00:003000 | 00:00:00:003000
------------------------------ Test Terminated --------------------------------
But if I want to put more params to stress it a bit, like
./sipp -sf register_client.xml -inf user21.csv -i local_ip kamailio_ip:k_port
-trace_err -r 100 -rp 80 -l 1000 -m 2000
is doing nothing.
Also is this test to "create 100 calls during each 80 milliseconds up to a
limit of 1000 calls in progress" means that the calls, here register method
calls not ths calls calls,
are keep-alive simultaneous till the 2000 one ends?
I guess the ones from -r flag, here -r 100 , would be concurrent, but what is
the default for the time till the sip session expires?
I want to be sure I have an minimum number of sessions for a while to see it
works. Maybe your explanation is clear but all these is new to me,
I want to learn it but maybe am a bit impatient :)
Thanks again, Adrian
-----------------------------------------------------------------------------------------
Take the power back!
On Monday, 21 March 2016, 10:38, sindelka <sinde...@ttc.cz> wrote:
Bună ziua Adi,
look at http://sipp.sourceforge.net/doc/reference.html#Online+help+%28-h%29
with special care about the meaning of -r, -rp, -l and -m command line
parameters.
Example:
sipp -sf your_scenario_name.xml -r 100 -rp 80 -l 1000 -m 2000
will create 100 calls during each 80 milliseconds up to a limit of 1000 calls
in progress. Terminated calls will be replaced by new ones until the total
number of calls will reach 2000. After that, no new calls will be added when
the running ones finish. The scenario execution ends when the last call
finishes.
This is unrelated to the contents of the injection file and/or to whether it
exists at all.
The limitations of your hardware may cause the actual performance to be lower,
especially if you are going to send RTP as part of the load test.
P.
Dne 21.3.2016 v 9:47 adrian Albu napsal(a):
Hi,
I was searching online for a way to test simultaneous sip sessions,
for example 1000 connected on it at the same time.
could not find an example,
the only starting point I found was:
http://comments.gmane.org/gmane.comp.telephony.sipp.user/3934
Is there an example somewhere?
Thanks, Adrian
-----------------------------------------------------------------------------------------
Take the power back!
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
