[OpenSIPS-Users] CDR search slow in CDRTool

[Tomas Andersen]

Hi again.

I have set up wireshark to check why the CDR rating engine uses so much time.

The following SQL queries are run from CDRTool to my OpenSIPS server:
select * from domain;
select * from trusted_peers;
Select rpid from subscriber where username = ‘+47xxxxxxxx’ and domain = ‘example.sip.com’

(with username and domain scrambled here)

The rpid select statement is run for each caller in the search period. What is strange is that these selects are only run each 10 second, and if I am searching
Within a period of time and there has been 7 different callers, it will take 70 seconds. After this the GUI is “released” and updated with the maching CDR list.

My subscriber table in open sips is empty. Why does this take so long?

Regards,
Tomas Andersen


From: Tomas Andersen
Date: Friday 27 November 2015 at 09:10
To: "users at lists.opensips.org<mailto:users at lists.opensips.org>"
Subject: CDR search slow in CDRTool

Hi

I have set up CDRTool to read CDRs from my radius database for OpenSIP calls. I am successfully rating calls, but everytime I search for CDR records using the
CDRTool GUI it takes 1-3 minutes before the search result window is shown.

If there are no matching records the result window is shown immediately. Does anyone else have any experience with this? I suspect that there might be a database lock,
Database connection pool problems or just some configuration error somewhere.

In my browser I get the following in my developer console / network (note the huge duration for the HTTP POST):

200 POST callsearch.pthml<destip> html105.41 kb 150212 ms
200 GET date picker.css<destip> css9.96 kb 14 ms

Followed by several lines of
304 GETs


When checking with Wireshark I notice that after the HTTP POST to callsearch, I get several TCP Keep-Alive messages as the server is slow..
After 2m 38 seconds everything is suddenly released and some HTTP GETs make the page to update.

I see nothing in syslog (from cdrtool) but some mysql connection statements.. No lock/unlock or similar statements..

I appreciate if anyone could enlighten me on this subject.


Best Regards,
Tomas Andersen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20151130/dff6f339/attachment.htm>