From 4ec7d835bd65106990aab6ac5d35f260292061e9 Mon Sep 17 00:00:00 2001 From: martinsumner Date: Sat, 4 Mar 2017 20:45:28 +0000 Subject: [PATCH] Add further info to HEAD path - and link to it --- docs/DESIGN.md | 6 +++++- docs/PATHS.md | 6 ++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/docs/DESIGN.md b/docs/DESIGN.md index 04784dd..f254165 100644 --- a/docs/DESIGN.md +++ b/docs/DESIGN.md @@ -86,7 +86,7 @@ All Ledger Keys created for any type must be 4-tuples starting with the tag. Ab The PUT path for new objects and object changes depends on the Bookie interacting with the Inker to ensure that the change has been persisted with the Journal, the Ledger is updated in batches after the PUT has been completed. -The HEAD path needs the Bookie to look in his cache of recent Ledger changes, and if the change is not present consult with the Penciller. +The [HEAD path](paths.md) needs the Bookie to look in his cache of recent Ledger changes, and if the change is not present consult with the Penciller. The GET path follows the HEAD path, but once the sequence number has been determined through the response from the Ledger the object itself is fetched from the journal via the Inker. @@ -122,3 +122,7 @@ Three potential recovery strategies are supported to provide some flexibility fo +n recovery the key changes will be recalculated by comparing the change with the current database state. + + + diff --git a/docs/PATHS.md b/docs/PATHS.md index 0963e23..6484292 100644 --- a/docs/PATHS.md +++ b/docs/PATHS.md @@ -7,6 +7,12 @@ To fulfil a HEAD request, the request needs to take the following path: - Check each persisted Level of the merge tree, and if not found - Return not_found +## TLDR + +There is a lot of activity involved in the HEAD path - but most of the activity is very quick and has minimal impact. + +The biggest chunk of effort by far, spending about two-thirds of the CPU time is when a value is found within a SST file's block - and the block needs to be de-serialised (using binary_to_term), and the block (which is a 32 element list of Keys/Metadata) needs to be walked to the nth element to return the Key/Value. This process takes around 300 microseconds in real world tests, but only 53 microseconds in local benchmark testing (possibly due to CPU cache effects). + Each of these steps is now described in more detail. ## The Bookie's Ledger Cache