tree a26dc413d0ea68b29fbb0a235b0bc4751a176001
parent 7f1cc26dc160072059e782a3e2f253e5a0a7fe57
author Ed Tanous <edtanous@google.com> 1659803766 -0700
committer Ed Tanous <ed@tanous.net> 1661790266 +0000

Sensor optimization

SensorsAsyncResp has existed for a long time, and has slowly morphed
from its intended usage (as an RAII response object) into a
conglomeration of all possible things that a sensor request could want.
This leads to a ton of inefficient queries, and lots of data being held
for much longer than we'd like.

This commit tries to start breaking things apart, and follow the
patterns we use elsewhere, passing AsyncResp where a response object is
needed, and passing specialized data structures only into the scopes
where they're needed.  This significantly increases the performance of
the /redfish/v1/Chassis/<>/Sensors/<sensor> URI.

The optimization changes the URI such that in includes both the sensor
type as well as the sensor name in the URI, meaning that from a given
tree, we can directly look up the sensor path, instead of having to look
up all sensor paths, and do a filename() compare on them.

Implementation-wise, there is one main difference in user-facing
behavior, in that instead of using a mechanized version of the sensor
name for the URI (aka /redfish/v1/Chassis/my_chassis/Sensors/my_sensor)
the URI now contains the sensor type (ex
/redfish/v1/Chassis/my_chassis/Sensors/temperature_my_sensor).  One
implementation note: because fan_pwm and fan_tach namespaces have an
underscore in them, we normalize these in the URI to fanpwm and fantach
respectively such that we can differentiate between the two without
looping, and special case them on the other side.  This seems like a
reasonable compromise.

The above means that when a request comes in to query the sensor, we no
longer have to pull all sensors to identify the one that matches the
name, and we can go directly to the mapper to determine which sensor we
need, with a GetObject query.  This significantly reduces the amount of
time to grab the information from a single sensor.

To accomplish this, the per-sensor methods needed broken down into
pieces that allowed loading a single sensor at a time, rather than a
complete GetManagedObjects call.  In practice, this just means breaking
out one helper function, such that the new code can directly call
GetAll.

In a few places, const std::string& had to be replaced with
std::string_view, because the new sensor API can directly inline its
const char* parameters for types, which allows it to avoid constructing
a string copy to do it.

Tested:
Redfish service validator passes on a S7106 system, and shows a timing
of ~40-50ms per sensor request, which is in line with what we'd expect
for a keepalive function using Session auth.

'''
curl --insecure -w "@curl-format.txt" -H "X-Auth-Token: nOIarWLRFkFN14qVONs0" https://192.168.10.140/redfish/v1/Chassis/Tyan_S7106_Baseboard/Sensors/temperature_sys_air_inlet
'''

returns timing that is on the order of 125ms.  On this setup,
ServiceRoot (which should do no dbus calls) returns in 90ms, so the
sensor implementation itself is on the order of 40% of the timing.

TelemetryService functions as expected
'''
curl -k --user "root:0penBmc" -X POST https://$bmc/redfish/v1/TelemetryService/MetricReportDefinitions/ -d '{"Id": "lxw1", "Metrics": [{"MetricId": "123", "MetricProperties": ["/redfish/v1/Chassis/Tyan_S7106_Baseboard/Power#/Voltages/0"]}], "MetricReportDefinitionType": "OnRequest", "ReportActions": ["LogToMetricReportsCollection"], "Schedule": {"RecurrenceInterval": "100"}}'
'''

Succeeds.

Also succeeds with MetricProperties set to:
/redfish/v1/Chassis/Tyan_S7106_Baseboard/Sensors/voltage_vcc5

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: If42f531b385c3b611b100c1c485a1e4e877c5512