Firewall: Aliases - squeeze some extra performance out of the dynamic captive portal aliases, the getConfigNode() works but still costs a bit more than I'm willing to spend.
The downside from direct config access is that we need to keep track locations in multiple spots, but since it's highly unlikely these locations will change, it's probably better to save some cpu cycles.
Firewall: Aliases - fix performance regression introduced in https://github.com/opnsense/core/pull/8368
The captive portal model is quite expensive to construct and for our aliases we only require the data underneath.
This commit organizes a couple of things, first implement an easier handle to load a random model from disk to test:
```
Config::getInstance()->forceReload('/path/to/test/config.xml');
$before = memory_get_usage();
$start = hrtime(true);
$mdl = new \OPNsense\Firewall\Alias(true);
printf(
"Alias: %.2f ms, retained PHP memory: %.2f MiB\n",
(hrtime(true) - $start) / 1e6,
(memory_get_usage() - $before) / 1048576
);
```
[4 lines not shown]
Firewall: Aliases - fix performance regression introduced in https://github.com/opnsense/core/pull/8368
The captive portal model is quite expensive to construct and for our aliases we only require the data underneath.
This commit organizes a couple of things, first implement an easier handle to load a random model from disk to test:
```
Config::getInstance()->forceReload('/path/to/test/config.xml');
$before = memory_get_usage();
$start = hrtime(true);
$mdl = new \OPNsense\Firewall\Alias(true);
printf(
"Alias: %.2f ms, retained PHP memory: %.2f MiB\n",
(hrtime(true) - $start) / 1e6,
(memory_get_usage() - $before) / 1048576
);
```
[4 lines not shown]
unbound: CSV import for overrides and aliases. Closes https://github.com/opnsense/core/issues/8354
Since we added the "quick" alias add/delete options from the overrides,
the data layout has been made flat enough to do this in bulk.
health: use logarithmic mbuf reporting, separate formatting responsibilities
Let the y-axis use compact metric formatting such as 10K or 1M.
Since a tooltip should be able to contain more detailed information, allow
separation through a tooltip_formats structure.
health: optimize quality graphs
Separate the percentages unit to a separate right-side axis, and
format the left-side axis logarithmically. Make sure the tooltips
contain the right units as well.
model:ContainerField - exclude volatile fields in isFieldChanged()
Volatile fields are usually initialized during model setup, but when untouched (no setter being called), they are marked changed.
Found this one by accident while looking at https://github.com/opnsense/core/issues/11048 which triggers validations for unchanged records.
System: Routes: Configuration - further refactor current static route updates for https://github.com/opnsense/core/issues/10569
This code should offer the same functionality as before, but starts with wrapping the "stashed updates" code into its own class, so we can extend that with the rest of the required logic.
In order to change system_routing_configure() to accept multiple targets for a single net, we likely should have a mechanism in place comparing our expected route configuration with the one configured, isolating that inside its own class is likely much easier for future maintenance.
In practice we always marked the networks touched by the UI in order to remove them before apply new ones, we call this action "claiming" now. Our primary issue is that given a running routing table, we can't really know which routes are inserted by us. Following the existing logic (which functioned for single targets), we could state that any network we manually configured (or are configuring) is ours to maintain.
At some point we may consider marking our routes with RTF_PROTO2 (Bird seems to be using RTF_PROTO1) to improve the filtering a bit further, but this is easy to implement later on given the plumning we need anyway.
