23 Mar
2004
23 Mar
'04
10:33 a.m.
On Mar 23, 2004 at 12:37, zeusng <zeus.ng(a)isquare.com.au> wrote:
Can anyone give me a realistic test case for measuring
SER performance? I've
been using sipsak to stress my SER server but am not able to interpret the
result.
Depends on what you want to measure. A more general benchmark would be
to measure the calls/s. However you need a tool able to generate and
terminate calls. Unfortunately I don't know of any such free tool.
You should also tune ser a little. You should start by recompiling it.
Make sure -DF_MALLOC is turned on and -DDBG_*_MALLOC off in Makefile.defs.
Also turn on -DNO_DEBUG (you could also compile with make
EXTRA_DEFS=-DNO_DEBUG). If you don't care about logs, add also -DNO_LOG
(not recommended for a production system).
Use a recent gcc (3.2-3.3) or icc (intel's c compiler). add CPU=your_cpu
to your make command line (e.g. make CPU=pentium4 ; by default ser is
optimized for athlon on x86 archs).
In your config file turn off Warning header (sip_warning=0)
and mhomed (by default is no, so you don't need to do anything unless
you have it explicitely turned on).
Here are some sipsak were run:
[siptest@sipuat siptest]$ sipsak -U -I -e 10000 -s sip:40@mysip.test -r 5060
-n 800 -z -vv
[siptest@sipuat siptest]$ sipsak -U -I -e 50000 -s sip:30@mysip.test -r 5060
-n 2 -z -vv
[siptest@sipuat siptest]$ sipsak -U -I -e 10000 -s sip:40@mysip.test -r 5060
-n 150 -z -vv
[siptest@sipuat siptest]$ sipsak -U -I -e 10000 -s sip:40@mysip.test -r 5060
-n 50 -z -vv
One of the result as follow:
All usrloc tests completed successful.
received last message 109125.023 ms after first request (test duration).
biggest delay between request and response was 46082.422 ms
10 retransmission(s) received from server.
9 time(s) the timeout of 5000 ms exceeded and request was retransmitted.
I guess a delay of 46s (46082.422ms) is definitely not acceptable. What
should I set for -n to be comparable to real world traffic.
I leave this for someone who knows sipsak better then me.
And what kind of result should I expect.
Side issue:
During my stress test, I experience the same problem Andres reported last
Nov.
udp_rcv_loop:recvfrom:[11] Resource temporarily unavailable
On linux, for a blocking socket, this means udp checksum error (the
kernel moves the skb in the socket receive buffer, wakes up the
process blocked on receive on the socket and then checks for
the checksum, if the checksum is bad will return an EAGAIN).
Try tcpdumping for the traffic (with -s 1514 ) and see if you can spot
bad checksums.
After I modify some kernel (Fedora Core 1, Linux 2.4.22) parameters, the
problem seems to go away. Anyone happy to prove the case?
# echo "8388608" > /proc/sys/net/core/rmem_max
# echo "8388608" > /proc/sys/net/core/wmem_max
# echo "8388608" > /proc/sys/net/core/rmem_default
# echo "8388608" > /proc/sys/net/core/wmem_default
I don't know why increasing socket receive/send buffers size would
affect this (I don't see anything relevant in the kernel code).
Andrei