Project

General

Profile

Bug #36453

Updated by Ernesto Puerta over 5 years ago

Endpoints providing information on OSD show linear size growth with OSD count.

* @/health@ grows 1-2 kB/OSD. It embeds all relevant Ceph maps (mgr_map, fs_map, osd_map, mon_map). Landing page is the main consumer of this endpoint, but it only needs osd_map to print "X total OSD (Y up, Z in)". _Solution_: calculate in a backend controller (@/summary@?) all the info needed for the Landing page.
* @/osd@ grows 1-2 kB/OSD.

Those would mean around 1-2 MB payloads every 5 seconds per dashboard instance for a 1000 OSD deployment. The resulting size can be highly varying as the payload is a plain-text JSON with lots of variable-length strings and numbers.

The above might impact on the following:
* *Networking*: especially no wireless ones.
** _Solution_: enable compression on the wire.
** _Solution_: delta JSON (PATCH-like).
** _Solution_: more compact data exchange formats (BSON, MessagePack).
* *Server-side*: caching either Ceph-mgr results or endpoint payloads could improve performance.
** _Solution_: cache ceph-mgr responses.
** _Solution_: using HTTP cache control (single-user multiple-requests).
** _Solution_: cache REST payloads internally (multiple-user).
* *Client-side*: user experience may be negatively affected by parsing and processing large chunks of JSON.
** _Solution_: lightweight data exchange formats (BSON, MessagePack).
** _Solution_: delta JSON (PATCH-like).
** _Solution_: more specialized REST Resources (instead of generalistic ones, like @/health@).
** _Solution_: REST API pagination support.
** _Solution_: REST API field selector/filtering support.

Back