OK, Do you think there is a easy solution or preffer rollback to a previous version until good performance?
I am actually just looking into the true root cause of this now as it’s annoying me. I have only just started using V5 on a new cluster I installed to replace an aging installation in the US that I use for high volume call center traffic. This particular installation currently has 10 freeswitch servers on it and I’m seeing daily account growth. Although I have it almost fully integrated with WHMCS so actions such as top-ups, account creation etc is all done from there, I still have some work to do on the auto provisioning of DIDs and IP maps. I’ll post a fix here as soon as I get to it, shouldn’t be long (as in the next couple hours providing no major incidents occur with any of my clients.
We are going to debug for it, thanks @jmurraysolutions for pointing the direction. In the meantime @petidier please log the concern at https://jira.astppbilling.org
Hi again, I had a chance to look at this, I’m suspicious of it being this commit: 5fromlab · iNextrix/ASTPP@5be5e5b · GitHub that is responsible where the use of gettext function is introduced.
Investigating further as I get the time.
False alarm, since gettext was still used on the get_language_text and isn’t used on customer_permission_list
1 Like
Found the issue, it’s common_model.php function get_dashboard_details.
This is called every time a page is loaded (including AJAX calls).
The problem is the query run on line 172.
$data_array['no_of_calls'] = $this->db_model->getSelect('(ROUND(sum(billseconds) / 60.0, 0) * 60) as total_seconds ,count(*) as total_calls', 'cdrs', $date)->row_array();
This query is what’s holding up the page load times (especially on pages which make multiple ajax calls (basically anything with a grid on it).
For every column header on a grid, and every button on a page, an individual ajax call is made to translate the header of the grid and check the permission of the user to use the buttons defined.
Each time an ajax call is made, the above query is run again, I can see no good reason for this and setting the line to the below does not appear to have affected my installation’s ability to load dashboard data, and page load is now significantly faster.
$data_array['no_of_calls'] = [];
Before Change:
After Change:
3 Likes
You´re a fucking God!! Thank for the solutions.
1 Like
Hello!
I don’t see any effect from the below changes.
I do however see that there a numerous instances of “async: ‘false’” in many ajax calls. You need to find every instance of this in the code and change to “async: ‘true’”. If you inspect using Firefox dev tools you’ll see this. I also linked jquery to a cdn incase there were changes to jquery itself.
“Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help http://xhr.spec.whatwg.org/”
You’ll also be interested that after optimizing the Nginx config the DB calls are still super slow and the CPU is idling while observing a page load.
Aaaaaand I have a theory why its slow, and that is because something in ASTPP is calling the following IP, not assets from the UI loading from CDNs in your browser, but from the server itself. If you block this then the ASTPP UI does not load. For me latency to this IP is about 150-300ms and who knows how many times its called with each ASTPP UI page refresh. EDIT: 22 calls per page refresh in ASTPP UI to the IP below.
IP: 34.117.59.81
81.59.117.34.in-addr.arpa name = 81.59.117.34.bc.googleusercontent.com.
For me, this worked on an install that handles anywhere between 1,500,000 and 2,000,000 calls per day. The UI became functional on the grid pages without showing the “page not responding” and the page load time went to just a couple of seconds from around a minute before.
In my situation, I handle high volume short duration dialer traffic and the CDR table gets extremely large. The larger it is, the longer that query takes to run. A low volume system may not see much of a difference by disabling that apparently useless query (I’ve witnessed no missing dashboard data etc) since if the CDR table is relatively empty, the query should complete in an acceptable time.
I agree there’s probably more issues in this case to resolve, however as I already got mine working to an acceptable level, I don’t have any plans to revisit this right now, I’d rather spend the time adding something of value like NPANXX rates (inter, intra, indeterminate) and LRN routing.
Did your CPU max during requests before the change? Also have you optimized Nginx config? It was slow for me before ( around 15 seconds), so I’d imagine that with more load yours would have taken much longer, but as soon as I changed the async property in all custom js occurrences it loads in about 2-3 seconds.
In my situation, I handle high volume short duration dialer traffic and the CDR table gets extremely large. The larger it is, the longer that query takes to run. A low volume system may not see much of a difference by disabling that apparently useless query (I’ve witnessed no missing dashboard data etc) since if the CDR table is relatively empty, the query should complete in an acceptable time.
I’m pretty sure that the UI doesn’t process the CDRs each time you load the page, and it certainly doesn’t require js. If your CPU spikes on the Mysql process then thats a large query, if it doesn’t then in my mind the slow down is due to the 22 requests it makes from the server itself per page load and some inefficient ajax calls (async true being one of them) on the client UI side.
I agree there’s probably more issues in this case to resolve, however as I already got mine working to an acceptable level, I don’t have any plans to revisit this right now, I’d rather spend the time adding something of value like NPANXX rates (inter, intra, indeterminate) and LRN routing.
I installed last week and when I have a gap I kick the tyres to see how its been put together.
If your server does not have internet access the UI WILL NOT LOAD.
I hope this helps others.
Hello, maybe you can tell me how to made that scan on the network activity? I’m having the same issue but this solution isn’t working for me.
Did you change the property in the js code from “async: false” to “async: true”? I think the server originating requests and async property would need to be done by the ASTPP team, and merged into the release tree for the code. So someone needs to report it on the bug tracker.
This information is really useful and it helped me too.
However, when I apply a filter in the CDR and I have several pages of 10 records each, when moving from the first to the following ones, the system stays processing.
What file should be modified so that the CDR also works quickly when performing a filter?
Thanks for your attention and help.
I fix this on my own servers by combining AJAX calls. Performance improvement is quite drastic if there are a large number of records. It also depends on how much latency there is between you and the server.
Here are my install notes for anyone that might be interested. It should just be cut & paste and you can easily enabled/disable this by changing one line.
There are two other simple speed improvements explained in that document. Combining AJAX calls makes the biggest difference though.
1 Like
Hi @sman123 who versión this fixed?, i make this adjust into astpp version 6.0, because is ver slow , into inspección network browser generate loop with get_language_text… get_language_text…get_language_text and so one …
Please help me
i make this fixed is not found… still with slow …
I think I did the fix on v4 community edition. It should work on v5, 6, 7, 8…900 etc. since they just keep changing version numbers without actually updating anything significant in the code.
You have to first figure out why your system is slow. My fix is for slow Ajax calls. ASTPP makes a lot of them, so if the you have more than a few ms ping time between you and the server it adds up. You can very easily figure out of your bottleneck is slow Ajax calls using Google Chrome Developer mode and then watching “Network” tab when you refresh a page.
1 Like
@sman123 It seems you need to be updated with recent improvements, monthly released tags, go check under releases
Anticipate a consistent occurrence over successive months.
1 Like