[Serusers] Performance tuning

[zeusng]

Theoretically, I would like to measure the calls/s. Since someone has create
the sipsak testing tool, I do want to test like what they have done at well.


On the other hand, a real world statistic like how many REGISTER, INVITE,
BYE are received by iptel, fwd, could benefit my projection on traffic
volume. Here, I'm not just talking about call volume, but also packet
traffic. Assuming each method has say 100 bytes and I am receiving 1G of
them every day, my service provider would charge me $$ on that.

Thanks for the tips on compile option. I do have most of them before the
stress test, except NO_DEBUG as I still need debugging information right
now.

As for your explanation of EAGAIN on linux, I do recall a different version
on some of the other discussion group. It talks about short of resource.
Also the man page shows a different story.

EAGAIN         The  socket is marked non-blocking and the receive
               operation would block, or a  receive  timeout  had
               been  set  and the timeout expired before data was
               received.
I'm not saying you are wrong, but that's not what I perceived.

The tuning parameter I did was based on a previous experience on another
application, namely SAP. It had a similar problem until I made the changes.
I must admit that I also change /proc/sys/fs/file-max and some other
variables as well.

One more interesting thing I observed during the stress test. If I have a
lot of REGISTERs  (say thousand) expire at around the same time, SER would
not process any new requests until all expired REGISTERs were gone. Any
explanation on this?

Zeus

> -----Original Message-----
> From: Andrei Pelinescu-Onciul 
> [mailto:pelinescu-onciul at fokus.fraunhofer.de] 
> Sent: Tuesday, 23 March 2004 8:34 PM
> To: zeusng
> Cc: serusers at lists.iptel.org
> Subject: Re: [Serusers] Performance tuning
> 
> 
> On Mar 23, 2004 at 12:37, zeusng <zeus.ng at 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 at sipuat siptest]$ sipsak -U -I -e 10000 -s 
> sip:40 at mysip.test 
> > -r 5060 -n 800 -z -vv [siptest at sipuat siptest]$ sipsak -U 
> -I -e 50000 
> > -s sip:30 at mysip.test -r 5060 -n 2 -z -vv
> > [siptest at sipuat siptest]$ sipsak -U -I -e 10000 -s 
> sip:40 at mysip.test -r 5060
> > -n 150 -z -vv 
> > [siptest at sipuat siptest]$ sipsak -U -I -e 10000 -s 
> sip:40 at 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
>