Hello All! After upgrading to 1.3.2 from 1.3.1 I'm encountered (similar to described in that list already) issue, e.g. openser answers unreliably slow to all messages (~40 seconds delay). DNS lookup related fix doesn't helps.
I'll try to find what exactly caused this delay (if it's openser-related issue and not something else).
On Tuesday 27 May 2008, Peter Lemenkov wrote:
After upgrading to 1.3.2 from 1.3.1 I'm encountered (similar to described in that list already) issue, e.g. openser answers unreliably slow to all messages (~40 seconds delay). DNS lookup related fix doesn't helps.
I'll try to find what exactly caused this delay (if it's openser-related issue and not something else).
Hi Peter,
if there is a general problem with the latest release, then this would be indeed a serious regression. I'm of course interested in further debugging this. Perhaps you can share further details of the problem? If you attach gdb or strace to the process in question, what does it show?
Another possiblity to find this problem would be a a bisect-search from 1.3.1 to 1.3.2.
Cheers,
Henning
Hi Peter,
First you need to find out if the delay comes from the network or from processing - just print a timestamp in the beginning of the request route and compare it with the timestamp from ngrep/tcpdump - by doing this you will find out if the message is delayed at socket level.
If the delay is in script, use benchmark or timestamps to locate the area that uses the largest amount of time.
Regards, Bogdan
Henning Westerholt wrote:
On Tuesday 27 May 2008, Peter Lemenkov wrote:
After upgrading to 1.3.2 from 1.3.1 I'm encountered (similar to described in that list already) issue, e.g. openser answers unreliably slow to all messages (~40 seconds delay). DNS lookup related fix doesn't helps.
I'll try to find what exactly caused this delay (if it's openser-related issue and not something else).
Hi Peter,
if there is a general problem with the latest release, then this would be indeed a serious regression. I'm of course interested in further debugging this. Perhaps you can share further details of the problem? If you attach gdb or strace to the process in question, what does it show?
Another possiblity to find this problem would be a a bisect-search from 1.3.1 to 1.3.2.
Cheers,
Henning
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hello All!
2008/5/27 Bogdan-Andrei Iancu bogdan@voice-system.ro:
Hi Peter,
First you need to find out if the delay comes from the network or from processing - just print a timestamp in the beginning of the request route and compare it with the timestamp from ngrep/tcpdump - by doing this you will find out if the message is delayed at socket level.
If the delay is in script, use benchmark or timestamps to locate the area that uses the largest amount of time.
Folks, I'm really sorry for noise - after some debugging and testing we found that this is a definitely an issue with our software. More particularly, there is a bug in our Oracle PL/SQL-scripts. We did some mistakes that can be visible only under heavy load.
OpenSER is still reliable and stable :)
Hi Peter,
This is what I call a good news :).
Usually this is the main problem when you have multiple systems integrated in only one platform - at a point, if something goes wrong, it is not obviously (not to say difficult) to say who's fault is - and this because the effects are more visible than the cause itself ;)
Regards, Bogdan
Peter Lemenkov wrote:
Hello All!
2008/5/27 Bogdan-Andrei Iancu bogdan@voice-system.ro:
Hi Peter,
First you need to find out if the delay comes from the network or from processing - just print a timestamp in the beginning of the request route and compare it with the timestamp from ngrep/tcpdump - by doing this you will find out if the message is delayed at socket level.
If the delay is in script, use benchmark or timestamps to locate the area that uses the largest amount of time.
Folks, I'm really sorry for noise - after some debugging and testing we found that this is a definitely an issue with our software. More particularly, there is a bug in our Oracle PL/SQL-scripts. We did some mistakes that can be visible only under heavy load.
OpenSER is still reliable and stable :)
-
Bogdan-Andrei Iancu -
Henning Westerholt -
Peter Lemenkov