27 May
2008
27 May
'08
3:43 a.m.
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).
--
With best regards!
27 May
27 May
4:14 a.m.
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
5:45 a.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
9:53 a.m.
Hello All!
2008/5/27 Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>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 :)
--
With best regards!
10:31 a.m.
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(a)voice-system.ro>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 :)
5844
days inactive
5844
days old
4 comments
3 participants
participants (3)
-
Bogdan-Andrei Iancu -
Henning Westerholt -
Peter Lemenkov