| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Traffic Graphs widget puts a graph object for every interface into
the HTML of the widget. Underneath the graph object for every interface
makes the call to graph.php to get data for the graph, and the refresh
interval also keeps happening, which keeps gathering the data every
refresh interval for every interface.
This wastes a lot of CPU back on the pfSense box gathering data
repeatedly if the system has a lot of interfaces and only has the
Traffic Graph enabled for 1 or a few of them. e.g. on my poor little
Alix at home I had setup 6 VLANs to test some stuff, so I had WAN, LAN,
OPT1 and 6 tagged VLANS - 9 interfaces. When I enable the Traffic Graphs
widget on the dashboard, the Alix CPU is driven 100% trying to keep up
with gathering data for 9 interfaces every 10 seconds, even though I
only have 1 graph actually opened!
I couldn't see a way to enable/disable the graph.php object from
executing. So this change puts the object in and out of the HTML:
a) At first display the graph.php object HTML is only put in the
relevant "div" if the graph is actually set to be shown in the config.
b) When a graph is opened by the user, the Java Script puts the
necessary graph.php object HTML into the div. The graph data then starts
being requested...
c) When a graph is minimised by the user, the Java Script removes the
graph.php object HTML from the div. The actions of graph.php stop
happening.
I can see the difference by just watching "top" from the command line on
a low-power system and open/minimizing the graphs on the dashboard.
If there is a better way to enable/disable an object like this I am
happy to learn about it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The log and picture widgets were both using "iforma" and "submita".
Actually it did not break anything because it was only the form name
repeated, not id. And nothing was using these names.
Traffic Graphs widget was using just "iform". That is a bit dangerous
for the future. I got tricked when cut-pasting some code to make some
settings options for the Gateways widget. I kept "iform" and then
wondered for a while why my Traffic Graphs widget show-hide settings
would not save. There was traffic graph JS that referred to just "iform"
and that started modifying the "iform" in my new Gateways widget code.
Rather than having names "iforma", "iformb"... "submita", "submitb"...
it seems much less risk of accidental duplication if these are named
like:
name_of_widget_iform
name_of_widget_submit
I don't think there is any user-visible bug in 2.2.* - so this
standardization could just go into 2.3
|
| |
|
|
|
|
|
|
| |
Note that advertise is spelt with an "s" in other places in the GUI, so
making it consistent in services_ntpd - but maybe Americans do spell it
"advertize" these days?
|
| |
|
| |
|
|
|
|
| |
Original post: http://forum.pfsense.org/index.php/topic,59193.0.html
|
|
|
|
| |
Don't activate master "Save Settings" button on traffic graph min/max.
|
| |
|
| |
|
|\
| |
| | |
.
|
| | |
|
|/ |
|
|
|
|
| |
causing javascript error exception to be thrown while displaying span
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Share filter log parsing code instead of using copy/paste/code duplication.
* Reworked the JavaScript a little so it could also be shared
* Fix a large number of bugs, especially in the AJAX-based dynamic log viewer.
* Picks up some more detail from the logs, and more accurately determines the protocol of a given log entry.
* Adds a CLI log parser (filterparser.php)
* Removed some redundant/unused code
* Code cleanup/style fixes
* Added support for finding logged rdr rules from miniupnpd
NOTE: Due to the dynamic nature of upnp rules, the rule may not be present when checked.
|
|
|
|
| |
HEAD before the Dashboard import.
|
| |
|
|
|
|
| |
help with load times for many tunnels)
|
| |
|
|
|
|
| |
be a tad higher
|
| |
|
|
|