Optimising Live Diorama Data
An application reports its faults. It does not report its inefficiencies. A failed request raises an error, but a duplicate fetch stays unnoticed. Typical problems are:
- refetch a static page in its entirety every 5 seconds
- fetch all columns of a related table, just to fill a select field in a form
- sort 120,000 rows in the client, and ignore the
sortcapability of the source
Inefficiencies show as extra latency, high CPU usage, or network traffic. This chapter gives you the mechanisms to detect them and to avoid them.
A user interface repaints many times each second. It cannot wait for the network on each frame, so the rows must already be in memory. When the user scrolls, the framework fetches rows ahead of the viewport to keep the movement smooth.
Diorama keeps those rows in a redb file on disk, one file for each datasource. The rows therefore survive a move to another page, and they survive a restart.
A user interface is not the only consumer of a cache. Vantage is also designed for facade APIs and for live caches at the edge.
The goal is the same in each case: answer most requests without a request to the master source, and keep the local copy in agreement with that source. A correct cache answers immediately, and then pushes each change to the viewport when it arrives.
What slows the app down?
| Inefficiency | What happens | The damage |
|---|---|---|
| Repeated fetch | The application asks for a window that it already asked for. | One request for each timer tick or repaint |
| Redundant rows | Rows arrive that the cache already holds. | Bandwidth, with no change on screen |
| Off-screen updates | The source announces a change to a row that the user cannot see, and the view repaints. | CPU usage for data that nobody looks at |
| Undeclared columns | Each row carries fields that no table lists. | Bandwidth. A grid of five columns can cost megabytes for each screen. |
| Work in the client | The client sorts, searches, or counts locally. | CPU usage, and an answer that covers the loaded rows only |
| A full copy of a large table | The source cannot serve windows, so the client reads all the rows at open. | Memory, and a wait before the first screen |
| A total that no fetch can fill | The source states more rows than it serves. | Requests for the missing rows, for as long as the page stays open |
There is no best caching strategy. Each use case needs a different approach. Vantage lets you design and implement your own strategy, but you must first understand how the cache behaves and how to monitor it.
Vantage UI works well with its default behaviour. This chapter starts from that default, and then adjusts it.
Overview
| Section | What you do | What it answers |
|---|---|---|
| 1. The setup | Build the optimising project and open it in Vantage UI | How do I put a source that I control under a real client? |
| 2. Reading the Debug Stream | Make the source slow, empty the cache, and switch on debug for one datasource | What does my application ask for? |
| 3. Where the Work Happens | Remove capabilities and find where the work moves | Which work moved into my process, and what did it cost? |
| 4. Fetching What You Drop | Find repeated fetches, redundant rows, and columns that no view shows | How many of these bytes did anybody need? |
| 5. Faults: Errors, Outages & Lies | Inject failures, outages, and dishonest totals | Does the application continue, or does it stop? |
| 6. Locking It In | Make assertions from your measurements, over a run with a fixed seed | Will I know when this becomes worse? |
Start here: The setup