What does Sipper Call Rate Actually Represent?
phoenix6789
I've been struggling with getting higher traffic rates out of Sipper
since I started experimenting with the tool in early January.
Initially I was dealing with a lot of memory leak type issues ( some
caused by forgetting to invalidate a session, some caused by the
tool ). I believe my memory-leak issues have been reduced to a
drip...as I still see a somewhat linear upward progression of heap
usage the longer I have a scenario running...so something is still
leaking somewhere...possibly under Sipper...I don't know yet.
I have not been able to get a call rate exceeding 2 cps from my
scenario. "Calls per second" can be a misleading term, as I have
found it means different things to different people. What is the best
way to interpret the "calls per second" attribute of sipper? Is it
best to think of it as:
- Busy Hour Call Attempts ( BHCA ),
- Busy Hour Session Attempts ( BHSA ), or,
- Busy Hour Transaction Attempts ( BHTA )
I do believe part of my problem is that my CPU tends to spend a lot of
time running at 100% while running my scenario, even at 2 cps. This
would understandably lead to long thread pauses causing things to
timeout and misbehave in the traffic script environment. Even at 1
cps I do see CPU spikes to 100%. Initial traffic ramp is not too bad,
but after about a minutes of traffic, then the CPU is totally
loaded...this could be caused by Ruby object creation rates, Ruby GC,
and / or normal Sipper operations.
It hasn't escaped my attention that I could just chain together a
bunch of instances on other computers / blades to get the traffic rate
up, but before doing that I want to make my environment as optimized
as possible so I get the most benefit from parallel instances of the
scenario.
The other part of the problem is the complexity of my scenario -- I
have two controller scenarios running on my desktop interfacing to
different points of the system under test. I have a UAC controller
scenario which involves a total 33 messages ( SIP requests + responses
& HTTP requests and responses ) for one complete call, and a network
entity simulator running as an HTTP server ( involving a total of
about 40 messages ( HTTP requests + responses ) for one complete
call. From the perspective of BHTA...I'm doing great...but my BHCA is
quite low....and I'd like to raise it up somehow.
I had to write a custom statistics mixin module for tracking and
monitoring my traffic runs, which has helped me isolate and trap a
number of exceptions and holes in my traffic scenario...but now I
really need to figure the rate issue. I have only ERROR level logs
turned on.
My next attempt will be to get Sipper running a multi-core linux blade
and hopefully be able to ramp the traffic higher.
Any ideas other than the parellel server idea for how I can optimize
my controllers?
thanks,
Dave Adams.