Hi Antoine, The line that I really don't like is the "Segmentation fault". It suggests that something has been wrongly compiled or linked, or that we have a serious bug...
Other strange things are the step durations and CPS that don't seem to match the parameters that you configured. Can you please send the following files: - ims_bench.xml - manager.xml - report.xml How many SIPp instances are you running? Early versions of SailFin did not work (correctly) in UDP mode, so TCP mode has been added to IMS Bench SIPp in order to be able to benchmark it. Regards, Patrice -----Original Message----- From: Antoine Roly [mailto:[email protected]] Sent: Wednesday, May 26, 2010 10:08 AM To: Buriez, Patrice Cc: [email protected] Subject: RE: [Sipp-users] sipp ims bench Hi Patrice, Thanks for the documented response. I tried what you told me, and it almost works... I've increased the number of users (you were right about +/- 20000 users, I didn't know I need more) and set a low SAPS to make test on a sailfin instance running on a virtual machine (It's temporary, and it explains the very low SAPS rate in the result below). It works fine during the first step, but at the end of the step (10 minutes, with a stir time of 2 minutes) I can see this : 09:39:04.351|** IHS Summary ** R1 CPS=6 [930385ms] 09:39:04.351| sailfin_uac 00 (S+F)= 10170 F= 14 IHS= 0.13766% 09:39:04.351| *IHS ALL* (S+F)= 10170 F= 14 IHS= 0.13766% 09:39:04.440|CPU0 930513ms: 29.7030 MT: 3631676 MF: 1135916 09:39:04.762|Max duration (600000ms) (CPS:27) ! Next Step... 09:39:04.762|Updating CPS to 28 09:39:04.762|** Global Summary ** R1 CPS=28 [930796ms] {10 calls in 411ms => 24.331 CPS} 09:39:04.762| sailfin_uac 00 O= 12702 S+F= 11538 F= 15 E= 0.13001% 09:39:04.762| **ALL** O= 12702 S+F= 11538 F= 15 E= 0.13001% 09:39:04.762|SIPP_IHS: ** R1 FINAL IHS (6 CPS)** [930796ms] 09:39:04.762| sailfin_uac 00 (S+F)= 10179 F= 14 IHS= 0.13754% < 1.00000% 09:39:04.762| **ALL** (S+F)= 10179 F= 14 IHS= 0.13754% 09:39:04.762|Max duration (600000ms) (CPS:28) ! Next Step... 09:39:04.762|Updating CPS to 29 09:39:04.763|** Global Summary ** R1 CPS=29 [930797ms] {0 calls in 1ms => 0.000 CPS} 09:39:04.763| sailfin_uac 00 O= 12702 S+F= 11538 F= 15 E= 0.13001% 09:39:04.763| **ALL** O= 12702 S+F= 11538 F= 15 E= 0.13001% 09:39:04.763|SIPP_IHS: ** R1 FINAL IHS (7 CPS)** [930797ms] 09:39:04.763|No scenario attempted in this step ** STOP NOW ** Segmentation fault ...and the test stops. I don't understand why it stops, the "No scenario..." seems weird to me. Am I doing something wrong with the test? I was expecting the test will continue until the IHS is higher, and the proxy overloaded. Did I made any mistake or misunderstood something? At this point, after the seg fault I suppose, the report.xml file is not properly written, so I have to do it myself (just close some markup in the file) to use the doReport script. Here are the parameters I have set for the test StepTransientTime [60] StirTime [2] StirMaxIHS [1] StepTime [10] InitialSAPS [5] StepNumber [999] StirSteps [1] SAPSIncreaseAmount [1] TotalProvisionedSubscribers [800000] PublicIdentityFormat [subs%06d] UserRealm [open-ims.test] UserDomain [sippIP] PrivateIdentityFormat [usim%06d] DontPreRegisterButUseSippIP [1] UserPasswordFormat [abcdefgh] Have you an idea? I can send you any file you want (ims_bench.xml, report, ...) Another question, just for my information: why is TCP required for sailfin? Thanks in advance Antoine Le mercredi 12 mai 2010 à 15:00 +0100, Buriez, Patrice a écrit : > Hi Antoine, > > As previously mentioned, the new "DontPreRegisterButUseSippIP" option allows > the pre-registration phase to be skipped. > This means that the users' SIP address directly contains the "@IP:port" of > the SIPp instance, instead of "@open-ims.test" which would require a DNS and > an HSS in order to be resolved. > This also allows to consider users as already registered when the test > starts, so they can immediately be part of a call. > > Here is a quick reminder about how IMS Bench SIPp default configuration works: > - at the beginning, all users are assigned to pool 0 > - during the pre-registration phase, the ims_reg scenario transiently moves > users from pool 0 to pool 1, and then to pool 2 once users have been > registered > - during the real test phase, the ims_uac and ims_uas scenarios pick users > from pool 2, temporarily move them to pool 3 during the call, and return them > to pool 2 at the end of the call > > Using the "DontPreRegisterButUseSippIP" option, the SailFin-dedicated > configuration works as follows: > - at the beginning, all users are assigned to pool 0 > - during the real test phase, the sailfin_uac and sailfin_uas scenarios pick > users from pool 0, temporarily move them to pool 2 during the call, and > return them to pool 0 at the end of the call > > So, the pick_user() line is not strange, because users must be selected for > the call from a pool where they are considered as "registered", or at least > as "ready to be part of a call". > I am a bit more concerned about the "User pool id[0] is empty -> Quitting!." > line... > > Basically, this error means that there are no more users available in pool 0, > which suggests that all users are currently part of a call and have been > temporarily moved to pool 2. > There might be several reasons for that problem: > - either you did not provision enough users (using the > "TotalProvisionedSubscribers" option), with respect to the load (SAPS) and > the average duration of calls (HoldTime) > - or users are never returned from pool 2 to pool 0 at the end of the call, > for example because the SUT does not properly forward the BYE message... > > Since your problem occurs at Call-Id 10986, I think it's the first reason > here, and I guess you only provisioned about 20000 users. You need many more > of them! > If you can't figure out how to fix this, then please send me the > ims_bench.xml file that was generated by the ims_bench.pl script into the > newly-created ims_bench_XXX/ directory. > > Regards, > Patrice > > -----Original Message----- > From: Antoine Roly [mailto:[email protected]] > Sent: Wednesday, May 12, 2010 11:33 AM > To: Buriez, Patrice > Cc: [email protected] > Subject: RE: [Sipp-users] sipp ims bench > > Hi Patrice, > > First of all thank you for your response. > > I tried the solution you told me, it almost works... > In fact, the test starts correctly, I see the SIP messages sent and > received in the SIPp instance running on the Test System. After some > time, SIPp stops with the message > > "sipp.cpp: EXIT_TEST_RES_UNKNOWN quitting=1". > > In the error log file on the TS, i can see these lines > > sipp: The following events occured: > Created CConsole 0x9c3b488. > SUT h=10 l=4 SO_REUSEADDR=1. > SUT h=10 l=4 TCP_NODELAY=0. > SUT h=10 l=8 SO_LINGER=(1,1). > SUT h=10 l=4 SO_SNDBUF=262142. > SUT h=10 l=4 SO_RCVBUF=262142. > SUT h=11 l=4 SO_REUSEADDR=1. > SUT h=11 l=4 TCP_NODELAY=0. > SUT h=11 l=8 SO_LINGER=(1,1). > SUT h=11 l=4 SO_SNDBUF=262142. > SUT h=11 l=4 SO_RCVBUF=262142. > Set TSID: slot:0 TS1 (1). > accept return 18 [IP4: 192.168.4.100:47710]. > ~ASSIGNID=0xffffffff - 0x1. > ~ASSIGNID=0x1 - 0xffffffff. > Set TSID: slot:1 TS1 (0). > User pool id[0] is empty -> Quitting!. > Quitting!. > Call '[email protected]' - pick_user() returned NULL. > Call '[email protected]' - Action 'move_user' without a user > assigned!. > !! ERROR !! There should have been calls in SYNC !!. > C:'[email protected]', T/O sailfin_uac:2 without ontimeout. > C:'[email protected]' [0xc0615d0/10985] Aborting! sailfin_uac:2. > 2010-05-12 10:38:50.526: CSutSocket::HandleEvent POLLIN: could not find > a call for Call-ID "[email protected]". > CSutSocket: Enter congestion h=11 s=502 ret=166 o=336. > CSutSocket::HandleEvent POLLOUT h=11 s=565831 ret=89776. > CSutSocket::HandleEvent POLLOUT h=11 s=552917 ret=82536. > CSutSocket::HandleEvent POLLOUT h=11 s=526629 ret=89776. > CSutSocket::HandleEvent POLLOUT h=11 s=439378 ret=88328. > CSutSocket::HandleEvent POLLOUT h=11 s=351050 ret=86880. > CSutSocket::HandleEvent POLLOUT h=11 s=264170 ret=88328. > CSutSocket::HandleEvent POLLOUT h=11 s=177353 ret=85432. > CSutSocket::HandleEvent POLLOUT h=11 s=91921 ret=86880. > CSutSocket::HandleEvent POLLOUT h=11 s=5041 ret=5041. > CSutSocket: Leaving congestion... h=11 ret=5041. > sipp.cpp: EXIT_TEST_RES_UNKNOWN quitting=1. > final cleanup. > > On the manager side, all I see is TS1 is deregistered and the test > stops. > > Did I made a mistake, or forgot something? > > The line with the pick_user() seems strange to me, indeed there's no > preregistration in this case, so obviously if the system try to pick a > registered user it will fail... > > Do you have any idea where the problem could come from? > > Thanks in advance > > A. > > > > Le lundi 10 mai 2010 à 18:22 +0100, Buriez, Patrice a écrit : > > Hi Antoine, > > > > IMS Bench SIPp now works with SailFin, since SVN revision 587, so please > > make sure that you "svn co" a "recent" version. > > This was tested using SailFin v1-b60g, jdk-6u14, and a sample Invite > > servlet, which were downloaded from: > > https://sailfin.dev.java.net/downloads/downloads.html > > http://java.sun.com/javase/downloads/index.jsp (now listing jdk-6u20), and > > https://sailfin.dev.java.net/source/browse/sailfin/sailfin-tests/community/systemtest/ > > > > On the SUT, install JDK and SailFin as documented, then unzip > > InviteServlet.zip and install the servlet as follows: > > - export PATH, JAVA_HOME and ANT_HOME as appropriate > > - start domain1 sample domain: > > cd /your/path/to/sailfin/ > > ./bin/asadmin start-domain domain1 > > - deploy Invite servlet: > > ./bin/asadmin deploy > > /your/path/to/the/unzipped/InviteServlet/dist/InviteServlet.war > > - stop domain1 sample domain: > > ./bin/asadmin stop-domain domain1 > > - you might want to adjust the SailFin SIP session timeout to 15, in order > > to prevent the SUT from dropping calls, in both: > > domains/domain1/applications/j2ee-modules/InviteServlet/WEB-INF/sip.xml > > and > > domains/domain1/generated/xml/j2ee-modules/InviteServlet/WEB-INF/sip.xml > > - then restart domain1 sample domain: > > ./bin/asadmin start-domain domain1 > > > > Install IMS Bench SIPp on the test systems as per the instructions provided > > at http://sipp.sourceforge.net/ims_bench/reference.html#Installation > > Then, instead of using the ims_bench.pl script with its default IMS UDP > > configuration, use it as follows: > > cd /your/path/to/ims/bench/sipp/ > > ./scripts/ims_bench.pl scripts/sailfin.xmt > > Navigate the menus to define the IP addresses of the SUT and TS instances. > > Please note that the Traffic Set relies on the provided sailfin_uac (and > > implicit sailfin_uas) scenarios. > > You will also notice that the new options "TransportTCP" and > > "DontPreRegisterButUseSippIP" are set to "1". TCP is required for SailFin, > > while skipping registration allows benchmarking a SUT that does not > > implement the HSS (such as a simple proxy). > > Quit and "generate the benchmark run files", then run IMS Bench SIPp as > > usual. It should work! > > > > Regards, > > Patrice > > > > -----Original Message----- > > From: Antoine Roly [mailto:[email protected]] > > Sent: Monday, May 10, 2010 3:55 PM > > To: [email protected] > > Subject: [Sipp-users] sipp ims bench > > > > Hi all, > > > > I'd like to test a small SIP server running on Sailfin, and made some > > overload test. Is it possible with SIPp IMS Bench? I have read the doc > > and saw that "IMS Bench SIPp should work in the situation just the same > > way as it works with SUTs that simply proxy the cal" so I suppose it is > > possible. Am I right? > > > > I have just installed the software and run ./scripts/ims_bench.pl. I was > > expecting to have two SIPp instances configured, while the SIP proxy > > will be between these instances but both of them act like SIP UAC. > > Should I write myself the scenario xml file and run SIPp on the UAS > > side, while the two TS will generate trafic? Or is it possible to run > > benchmarks with specific scenario files, in this case SIPp will generate > > trafic with Poisson distribution but using my files? > > > > And is the use of OpenIMSCore mandatory? Or could I use SIPp with other > > SIP softwares? > > > > I'm a bit confused, did I made a mistake or not understood something > > about the soft? > > > > Thanks in advance > > > > A. > > > > --------------------------------------------------------------------- Intel Corporation NV/SA Rond point Schuman 6, B-1040 Brussels RPM (Bruxelles) 0415.497.718. Citibank, Brussels, account 570/1031255/09 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ------------------------------------------------------------------------------ _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
