|
@@ -113,3 +113,59 @@ Not a procedure on paper - this was run:
|
|
|
It recovered 27,433 documents in 95 collections and served all 9 workflows by
|
|
It recovered 27,433 documents in 95 collections and served all 9 workflows by
|
|
|
name, 7 credentials and 1 user. A 2 MB file downloaded byte-exact, which is what
|
|
name, 7 credentials and 1 user. A 2 MB file downloaded byte-exact, which is what
|
|
|
proves the encryption key came through - counting documents would not have.
|
|
proves the encryption key came through - counting documents would not have.
|
|
|
|
|
+
|
|
|
|
|
+## Indexes
|
|
|
|
|
+
|
|
|
|
|
+Declared at webserver startup, idempotently, so a fresh install or a restored
|
|
|
|
|
+backup gets them without anyone remembering to. They live in the database, not
|
|
|
|
|
+in a config file.
|
|
|
|
|
+
|
|
|
|
|
+Only what was measured to help - an index costs write throughput, so one that
|
|
|
|
|
+buys nothing is a cost paid for ever:
|
|
|
|
|
+
|
|
|
|
|
+| index | before | after |
|
|
|
|
|
+|---|---|---|
|
|
|
|
|
+| `sessions.refreshToken` | 24 ms | **1 ms** |
|
|
|
|
|
+| `executions.workflowId` (miss) | 1124 ms | **1 ms** |
|
|
|
|
|
+| `workflows.projectId` | small today | scales with the workflow count |
|
|
|
|
|
+| `users.username`, `users.email` | 1 row | scales with the user count |
|
|
|
|
|
+
|
|
|
|
|
+`executions.workflowId` still takes ~800 ms when it *hits*, and that is not the
|
|
|
|
|
+index: cost scales with rows returned, about 30 ms per execution document,
|
|
|
|
|
+because each carries every node's input and output. A miss answers in 1 ms,
|
|
|
|
|
+which is what shows the lookup itself is fine. Making that query fast needs the
|
|
|
|
|
+documents to stop carrying node output, not another index.
|
|
|
|
|
+
|
|
|
|
|
+**`executions.startedAt` was declared and dropped again.** Measured, it changed
|
|
|
|
|
+nothing - a range with `limit 1` still took 300 ms and a sort by it 422 ms.
|
|
|
|
|
+Ranges and sorts are not served from an index in this version. Executions are
|
|
|
|
|
+the most-written collection here, so it was pure cost.
|
|
|
|
|
+
|
|
|
|
|
+## Versioning
|
|
|
|
|
+
|
|
|
|
|
+Off everywhere except `workflows`. Only two places read a version - the workflow
|
|
|
|
|
+controller (the editor's picker, publish, restore) and the runner (loading the
|
|
|
|
|
+published version to run) - and both are about workflows.
|
|
|
|
|
+
|
|
|
|
|
+Everywhere else the history was written on every save and read by nothing, with
|
|
|
|
|
+`maxVersions` 0 meaning unlimited. `executions` is the worst of it: 481 MB, and
|
|
|
|
|
+each run writes its record two or three times.
|
|
|
|
|
+
|
|
|
|
|
+Disabling stops new versions being recorded; history already written stays
|
|
|
|
|
+readable, so it is reversible and **reclaims nothing by itself** - the existing
|
|
|
|
|
+history directory is still there.
|
|
|
|
|
+
|
|
|
|
|
+## File expiry
|
|
|
|
|
+
|
|
|
|
|
+Every stored file has one. A file's TTL could only be set at upload before 2.8,
|
|
|
|
|
+so anything written before that was immortal, and `FileRecord` carries no expiry
|
|
|
|
|
+field - a file that already has one cannot be told from one that does not, so
|
|
|
|
|
+the sweep sets one on all of them.
|
|
|
|
|
+
|
|
|
|
|
+90 days was chosen: source photos, generated images and downloads, all either
|
|
|
|
|
+regenerable or already published elsewhere.
|
|
|
|
|
+
|
|
|
|
|
+**The documents that point at those files do not expire yet.** No workflow or
|
|
|
|
|
+project declares a retention, so in 90 days those records will name files that
|
|
|
|
|
+have gone. Setting a retention on the project closes that - it covers documents,
|
|
|
|
|
+executions and files together.
|