decentraland / world-storage-service / 28469033931

99%

push

github

feat: cache storage reads and cut JSON CPU on the hot paths (#110)

* feat: cache storage reads and cut JSON CPU on the hot paths

Adds a dedicated in-memory cache (per-instance, TTL-bounded) and removes
redundant JSON work on the most-used world/player value endpoints.

Caching (storageCache, separate from the places cache):
- world & player single-key getValue: read-through + write-invalidation
- world default GET /values page + unfiltered total count: read-through,
  invalidated on any write to the scene
- knobs: STORAGE_CACHE_ENABLED / _TTL_SECONDS / _MAX / _MAX_VALUE_BYTES /
  _MAX_LIST_BYTES. TTL bounds cross-replica staleness (in-memory caches
  cannot be invalidated across instances).

JSON / CPU:
- getValue selects value::text and the handlers return it verbatim, skipping
  node-postgres' JSON.parse of jsonb and the framework's response
  JSON.stringify (on both miss and cache hit).
- upsert serializes the value once: validate*Upsert returns the JSON string,
  reused by setValue and the response; setValue stores it directly and drops
  RETURNING value (no echo-back + re-parse).
- covering indexes (world_name[, player_address]) INCLUDE (key, value_size)
  so the per-write size aggregation runs index-only.

Behavior change: GET /values/:key (and player equivalent) now return 404 only
when the key is absent, not when the stored value is falsy (0/false/""/null).

* perf: serve GET /values without parsing each row's jsonb

listValues now selects value::text and assembles the page into a JSON array
string by splicing the value text verbatim, so node-postgres no longer
JSON.parses every jsonb row and the response layer no longer re-stringifies the
page. The default-page cache stores the assembled text, so cache hits are served
raw too. Only the (small) keys are escaped. Response shape is unchanged.

* perf: build storage-size covering indexes concurrently

Create the (world_name[, player_address]) INCLUDE (key, value_size) indexes with
CREATE INDEX ... (continued)

281 of 286 branches covered (98.25%)

Branch coverage included in aggregate %.

101 of 101 new or added lines in 11 files covered. (100.0%)

944 of 947 relevant lines covered (99.68%)

64.86 hits per line