- January 4, 2019 at 5:59 pm #533
Hey Terry! Happy new year! So far things have been running well, no weird errors or anything.
I did notice one thing – some of the reports take a while to run, like for me particularly, looking at failed call legs. A report takes 10-15 minutes to run, and at the same time the UI becomes unresponsive until the report completes.
I noticed the VM only had 1 CPU, so I added one thinking that might help. Then it only uses ~50%, so I’m guessing everything is single threaded.
Anyway, I don’t know if you have it in your road map to allow more CPUs to be utilized, but wanted to throw it out there. Thank you, have a good weekend.January 7, 2019 at 6:46 pm #534
I’m not sure that multiple threads (cpus) would help in this case, where we have a single user running a single mysql query. Now it would help if you have other users using the system at the same time who want to run queries (that is, as long as they aren’t querying the same mysql table, where a lock has been placed). Lots of moving parts, however I will definitely put some thought into how to better support multiple threads.
One thing that I will do for the next release is to add indexes on the database, which should significantly speed things up. I had planned to add indexes to normal user searches, but I’ll look at the failed call search as well.January 7, 2019 at 11:18 pm #535
ah ok, yea it would be interesting to see how indexing would impact it just by itself.
I haven’t run a lot of other searches so far, the ones I have seem pretty snappy.January 13, 2019 at 10:26 pm #553
I’ve released a new version that will automatically create indexes on the database. Let me know if this is any faster.January 15, 2019 at 1:47 pm #555
I seem to have a problem separate from VOIPDetective I need to sort out. I have 4600 failed call legs so far today, mostly code 1. Something weird going on there, may have to open a support case with Cisco. A lot of it is repeat offenders, mostly analog lines on VG224s. Very strange.
So I’m assuming it’s the volume of data we’re generating, but I ran the report yesterday and it took about 45 minutes.January 15, 2019 at 8:43 pm #560
wow – 45 minutes is a long time. I’ve added pagination (is that a word?) to the admin reports, so I’ll make the default report display the first 100 errors, instead of all of them. That should prevent the initial page load from being so huge. The admin search is pretty intense because it tries to pull in a ton of data, including all CMR information (jitter, dropped packets, etc).
As to your unallocated number issue – I had an issue on one of my analog gateways where I had put an invalid (unallocated) number into the Attendant DN section of each port on my gateway. Calls into that port attempted to hit the attendant DN and failed. You may want to look at that.February 12, 2019 at 5:10 pm #592
I’ve added a few more indexes to speed up performance. I’ve also added pagination to the admin search, so it won’t try to return all one million results on the same page.February 14, 2019 at 11:06 am #598
I just installed the update – this seems much better. It returned 2200 records instantly. Good job! I like the new look too.February 17, 2019 at 3:10 pm #599
That’s great – I’m glad the speed improved. Also, thank you for the kind words.
The next version will give some limited ability to change background colors, font sizes, etc.
- You must be logged in to reply to this topic.