@FreshJR , check out this
commit. It provides a smoother first load here (tested with around 275 connections), as the browser won't be retrieving and sorting the data through Ajax while it's already doing so from the initial page load.
I also tried to separate pie chart from conntrack table, but the Chart animation was horribly jerky as the browser was trying to sort the conntrack data at the same time.
I also did some optimizations to the Table sort code, tho you're no longer using that. Sorting should be a tad faster now.
Hi
@RMerlin,
I already caught that the table was generated twice on initial load. I already had that line removed from my variant of the Qos_Stats page.
Code:
get_data();
//draw_conntrack_table(); get_data() already draws table
Its was not the sort functions from the tableApi that were the culprit for slow and non-responsive load times.
It is the generation of the table html code with the use of jquery calls.
I did the following testing done with ~500 connections.
With the string concatenate method, I generated the table in ~30-50ms.
When I used a more optimized jquery approach I hit 150ms.
With Asus' tableApi's jquery method, it always ended up being 300-500ms for generation.
That was really terrible in terms of responsiveness and CPU intensity.
I choose my concat method. Its so fast there is no reason to worry about performance.
I am actually sorting+redrawing the entire table + the pie charts anytime a user selects a device from the device filter.
There is zero choppiness, even on mobile devices, and you can scroll through the devices with your keyboard arrow keys as fast as you please.
I only limited the table to 500 entries was to eliminate a very long scrollbar and not due to performance issues. You can easily crank that sucker up without worry.
I can whip up the QoS_Stats with my table generation approach and non of the others stuff I ended up including, BUT only if you are interested in using it.
I don't want to waste my time if you are not interested.
So give my page a shot and see for yourself. I did retain the sort features of Asus' tableApi.
--
I simply used java's built-in sort(), both string and integer variants.
The sorting of the table for all purposes can be considered instant.
I am actually sorting the tabledata TWICE and the double sort takes less than ~3ms for a multicolumn sort.
The only sort that is a negligibly slower (~5ms) is the ip column sort since I end up expanding all the ip addresses using the full_IPv6() function before performing the string sort. I do think that was the wrong area to optimize for performance gains.
--
I can also optimize the string sorts I am using, but I already consider my approach to the process very efficient, so I am not going to bother.
