| commit | 72c3ae33bd127f8cd5887000a45adf13a56c7582 | [log] [tgz] |
|---|---|---|
| author | Nan Zhou <nanzhoumails@gmail.com> | Fri Apr 22 17:53:28 2022 +0000 |
| committer | Ed Tanous <ed@tanous.net> | Wed Jun 01 20:17:42 2022 +0000 |
| tree | 5bf116f88a15b77deecfeff532388e2c55996d9c | |
| parent | de167a6f30c0f32683480e06c6e81cfc9d4eb37b [diff] |
Expand query: reimplement the way to do subqueries
For any expand query, the current implementation does all queries in a
single MultiAsyncResp, where the code sends a bunch of requests without
Query parameters. This makes it impossible to invoke efficient expand
handlers, since efficent handlers will only be invoked when a query has
$expand in its parameters. (Delegation only happens when the query
contains query parameters)
To solve it, in this commit, we proposed to send a bunch of requests
**WITH** Query parameters in MultiAsyncResp. This makes
"/redfish/v1/Chassis/chassis?expand=.($levels=2)" be able to invoke
efficient expand handlers that we developed for sensors, which existing
implementation can't do. This decreases latency by nearly 100 times (the
improvement that efficient sensor expand handler provides) on real
hardware which contains 5+ chassis and totally 220+ sensors.
This commit aligns with future $select support well, since the recursive
queries can add $select as part of the query parameters.
With this commit, though we create multiple MultiAsyncResp objects
memory doesn't increase significantly; part of the reason is that we are
not copying Query anymore in MultiAsyncResp.
No out-of-memory issues are found when 4 threads are querying
expand=levels=6 at the service root on a real large hardware which
contains 2+ sockets, 5+ chassis, 220+ sensors, 30+ DIMMs, etc.
Tested:
1. On real hardware, /redfish/v1/Chassis?$expand=.(level=3) is giving
the correct result and invokes efficient sensor Expand handler
2. stress test
```
for i in {1..4};
do
echo "thread $i"
wget -qO- 'http://localhost:18080/redfish/v1?$expand=*($levels=6)' > "/tmp/$i.log" &
done
for i in {1..1000};
do
top -b -n 1 | grep bmcweb >> /tmp/bmcweb_ori.log
sleep 1
done
```
Results
```
25878 2856 root R 194m 20% 1 38% /tmp/bmcweb_after
19005 2856 root R 215m 22% 1 36% /tmp/bmcweb_ori
```
Signed-off-by: Nan Zhou <nanzhoumails@gmail.com>
Change-Id: I0e661db0263f56dd0cab66047a0a5d4fff31b69a
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D flags that correspond to options in bmcweb/meson_options.txt and then compiling. For example, meson <builddir> -Dkvm=disabled ... followed by ninja in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja -C builddir test ninja -C builddir coverage
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1 algorithm. The certificate
C=US, O=OpenBMC, CN=testhost,SHA-256 algorithm.