I forgot to add. The version of SIPp used was 1.1rc6 (win32 version) from the Sourceforge website - which according to the site is the latest stable release. Most of the testing I did that time using SIPp was based on the uac scenario (
uac.xml - Basic Sipstone UAC scenario) as I have not played around with it extensively yet.
I think I may have to re-do some of these tests again with SIPp anyway to see if there are any other settings that might affect the results and maybe try and get some more formalised results.
Merry Christmas to All.
On 12/17/06, Klaus Darilion <klaus.mailinglists@pernau.at> wrote:
Hi MAx!
make sure to use newest sipp. AFAIR there were several patches to sipp CVS
version for high performance testing (for sure I know thre were TCP
problem. Maybe there were also UDP problems too)
Further I would be interesting if the same problem happens when using TCP
too. In my tests TCP achieved higher performance then UDP (UDP's
retransmissions kills the proxy when getting to the performance limit -
like an DoS attack).
regards
klaus
On Fri, December 15, 2006 23:10, Jiri Kuthan said:
> if you happen to have a PCAP file with the incident, let me please know.
>
> -jiri
>
> p.s. even if you didn't tweak timers, the results may be suboptimal
> because
> the software version you are using is having rather indeterministic timer
> subsystem.
> For example, the recent measurements
> (http://www.iptel.org/ser/doc/performance)
> show quite scattered server responsiveness under high load. (Note though
> that
> the measurement results were achieved in a best-effort manner based on the
> tester
> knowledge and understanding of openser and that the result are not
> officially confirmed
> by the OpenSER project.) Whether it is indeed the cause is not certain
> though
> -- this looks really like a stealth bug.
>
>
> At 15:58 15/12/2006, Max Gregorian wrote:
>>Thanks very much for all the replies. I shall try and post a config and
>> traces as soon as I can get them from the office.
>>
>>Some more information, if it helps:
>>
>>Server specs:
>>- HP ProLiant DL360 G4 (1U rack servers)
>>- 3 GHz processors (800 MHz FSB)
>>- 1 GB RAM
>>- 10K rpm SCSI HDs (in a RAID 1+0 Mirror)
>>
>># Servers are running OpenSER 1.0.1 (no-TLS).
>># Servers are listening on 3 ports (both tcp and udp for each port), so
>> in openserctl ps I am seeing 4 child processes for each port.
>># Servers running CentOS Linux 4.3
>># MySQL installed when CentOS was installed but not running and not
>> currently being used with Openser.
>>
>>
>>Things I have pretty much managed to eliminate are:
>>1. It's doesn't seem to be hardware. The specs for the servers are more
>> than sufficient I think.
>>2. It doesn't seem to be traffic/load related as I see these problems on
>> 2 brand new servers I have just installed with no traffic on them.
>> However, it does seem to get worse with more traffic.
>>3. I don't think it's database related as I have deliberately not
>> configured mysql on any of the servers in case of database performance.
>>4. I haven't played with the timers at all so far.
>>5. I haven't configured nscd yet, but as far as I can tell it's not
>> caching DNS.
>>6. Though openser is listening on tcp ports as well, currently only the
>> udp ports are being used as most of our customers use hardware phones. In
>> any case, I haven't as yet seen as requests on tcp.
>>7. I am not sure it is DNS as in the tests I ran I sent requests directly
>> to the external IP of the server and not to the domain name it is
>> responsible for. Also the test servers are now only responsible for one
>> domain, but in future will have more than one.
>>8. Also TTL on the domain name is really short. Ping from the server
>> itself TTL=64 and ping times are low as you would expect (< 1ms when
>> pinging from the server itself). Ping from outside the network (from the
>> internet - for me - tp the domain was) 12ms (average), no packet loss,
>> TTL = 53.
>>9. I have not setup any internal DNS entries for the domain. Servers are
>> resolving domain from entries in /etc/hosts.
>>
>>Like I said, it doesn't happen all the time - just maybe once or twice
>> every hour on the servers with more traffic.
>>
>>I ran SIPp pointing at one of the new servers last week and at around
>> 100CPS I was seeing about 2,000 out of approx. 10,000 calls were failing.
>> Setup was UAC -> openser -> UAS (Both UAC and UAS were running on the
>> same machine, but different ports). Again there is no traffic on these
>> servers now so I have no idea why so many failed calls.
>>
>>I am not sure if any of this information helps, but I am certainly open
>> to suggestions on things to try.
>>
>>Thanks in advance.
>>
>>
>>
>>On 12/14/06, samuel <<mailto:samu60@gmail.com>samu60@gmail.com
> wrote:
>>It might be due to a DNS query....whenver a request has to be
>>forwarded to a domain, openSER makes a DNS query to resolv the IP.
>>During this operation, the child processing the request will not
>>answer to further incoming messages.
>>
>>it also can be happening due to a spiral loop that stays on the server.
>>
>>Without further information (confg,logs) it's hard to tell which is
>>the reason...
>>
>>hope it helps,
>>Samuel.
>>
>>without more information
>>
>>2006/12/14, Max Gregorian
>> <<mailto:
gregorian442@googlemail.com>gregorian442@googlemail.com>:
>>> Hi all,
>>>
>>> Just wondering if anyone else has had this problem. I have noticed
>>> while
>>> tracing on my OpenSER server, that every now and then the server
>>> receives a
>>> packet which it does to respond to immediately, resulting in a string
>>> of
>>> packets being sent to the server and then the server responding a few
>>> seconds later. This does not happen all the time, just say maybe once
>>> or
>>> twice every hour. The rest of the time the signaling is correct and
>>> responses follow request packets in the correct order.
>>>
>>> What I am trying to figure out is whether this is a load traffic issue
>>> (i.e.
>>> can the server not handle too much load), and if so is it OpenSER or
>>> the
>>> network or the server in general? I have run diagnostics on the servers
>>> and
>>> there is nothing wrong with the hardware.
>>>
>>> On the other hand Could this be related to any timer issues? I remember
>>> there was mention of timers in SER but are there any default timer
>>> settings
>>> that can be tweaked?
>>>
>>> Thanks in advance for any response.
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> <mailto:Users@openser.org>
Users@openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>
>>
>>_______________________________________________
>>Users mailing list
>>Users@openser.org
>>
http://openser.org/cgi-bin/mailman/listinfo/users
>
> --
> Jiri Kuthan http://iptel.org/~jiri/
>
>
> _______________________________________________
> Users mailing list
> Users@openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>