Status > Dashboard pretty CPU-intensive
-
I inspected the element and is generated with data on the path element. Is making a SVG with this data with the command M .
Don't know if the new method is better in performance CPU. A sample to teste would be great.
-
yeah I have 4 graphs open can tell a big difference in cpu
-
@mais_um:
Hi
I hope they include the new traffic graph and status graphs. The load will be, mostly for the client and not to the pFsense machine.https://forum.pfsense.org/index.php?topic=108290.msg604340#msg604340
Thanks for pointing that. Is one more reason to switch to the new graph.
Correct, more of the load will be on the client side. Although there are apparently optimizations we can make to how the interface data is gathered (at a later time) that will improve server-side performance.
The traffic graphs are dynamic now (and at a stage where I need to do some clean up):
In the end, you should be able to have multiple interfaces on one graph (although I don't recommend putting the lan and wan on the same graph…kind of pointless :))
-
If the graph is realtime the Date & time info is kinda pointless.
I ready to test it :)
-
@mais_um:
If the graph is realtime the Date & time info is kinda pointless.
Yea, the old one had the date/time there so I added it…when there was also more real estate up there. I may just change the X axis to be more clear (either add the hour, or a label).
-
Uhhh that's sooo cool :)
-
@mais_um:
I ready to test it :)
I am going to hold off on the traffic graphs for the 2.3.1 snapshots so there is plenty of time to test.
-
??? That hurts :P. x.x.1 should not be to long after a x.0 release, usually.
-
@mais_um:
Hi
I hope they include the new traffic graph and status graphs. The load will be, mostly for the client and not to the pFsense machine.https://forum.pfsense.org/index.php?topic=108290.msg604340#msg604340
Thanks for pointing that. Is one more reason to switch to the new graph.
I don't recommend putting the lan and wan on the same graph…kind of pointless :))
but , if i have squid , or another proxy , the traffic is going to be different, then I believe that having the two selected becomes something useful, please correct me if I'm wrong.
-
From my understanding wan (out) = lan (in) and lan (out) = wan (in). Although, I could be mistaken, especially in cases where cache/proxy is involved. Regardless, you will have the option to do so, so we can find out in testing if need be.
-
I have two WAN's, is useful have WAN1 WAN2 and LAN i can make some mentally calc and inverse the sides (in/ou) but better have the 3. Jdillard speaks for that particular case on the last picture he shows, i think.
-
From my understanding wan (out) = lan (in) and lan (out) = wan (in). Although, I could be mistaken, especially in cases where cache/proxy is involved. Regardless, you will have the option to do so, so we can find out in testing if need be.
For most this is true… but with a caching proxy, LAN might see something served from the cache rather than actually hitting WAN for the data... so the data would still go out the LAN interface, but there would be nothing coming in on WAN.
And then there are those with multi-WAN setups... How about a drop-down or widget setting to pick whatever interface you choose, and just show in/out for that interface? Want to see multiple interfaces, add the widget multiple times.
I think waiting for 2.3.1 isn't a bad idea at this point.
-
@virgiliomi:
And then there are those with multi-WAN setups… How about a drop-down or widget setting to pick whatever interface you choose, and just show in/out for that interface?
It will be a multi-select box or similar that allows you to select any number/combination of interfaces (both in and out for each).
So far the options I have planned are: Select interface(s), invert outbound, and refresh interval.
Something else I was going to play with was a totals line, but that sounds more complicated than I originally thought.
@virgiliomi:
Want to see multiple interfaces, add the widget multiple times.
There currently isn't code in place that allows a widget to be used multiple times and configured in multiple ways, so that would have to be implemented first and would also be useful for the monitoring widget (that doesn't exist…yet?)