Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Materialized stakeholder view is too expensive #10234

Closed
cocreature opened this issue Jul 9, 2021 · 1 comment
Closed

Materialized stakeholder view is too expensive #10234

cocreature opened this issue Jul 9, 2021 · 1 comment
Labels
component/json-api HTTP JSON API team/ledger-clients Related to the Ledger Clients team's components.

Comments

@cocreature
Copy link
Contributor

cocreature commented Jul 9, 2021

I ran some tests so see how the materialized view compares to a separate table that we manage manually or not recording the stakeholders separately at all. The results are very clear: The materialized view gets significantly slower as size of the ACS increases despite various options to update it somewhat incrementally. The separate table on the other hand has basically no additional costs if we submit both in a single transaction.

I plotted the results. 1 step on the X axis corresponds to the insertion of 100 additional contracts into the ACS (so a total of 40000 contracts). Y axis is nanoseconds for the duration of the database transaction.

materializedview

code: https://github.com/digital-asset/daml/tree/json-oracle-experiments-materalized split into one commit per plot

While the materialized view is perhaps a bit easier to get right, the performance overhead is too large to justify it so we should switch away from this.

cc @S11001001 I might take look at this myself

@cocreature cocreature added this to the HTTP JSON API Maintenance milestone Jul 9, 2021
cocreature added a commit that referenced this issue Jul 14, 2021
Unfortunately the results seem to match up with my initial benchmark
in #10234

Benchmark            (batchSize)  (batches)  (numContracts)  Mode  Cnt     Score     Error  Units
InsertBenchmark.run         1000          1            1000  avgt    5   336.674 ±  42.058  ms/op
InsertBenchmark.run         1000          3            1000  avgt    5   787.086 ± 223.018  ms/op
InsertBenchmark.run         1000          5            1000  avgt    5  1181.041 ± 317.017  ms/op
InsertBenchmark.run         1000          7            1000  avgt    5  1531.185 ± 341.060  ms/op
InsertBenchmark.run         1000          9            1000  avgt    5  1945.345 ± 436.352  ms/op

Score should ideally be more or less constant but it goes up very
significantly as the total ACS size changes

fixes #10245

changelog_begin
changelog_end
cocreature added a commit that referenced this issue Jul 14, 2021
Unfortunately the results seem to match up with my initial benchmark
in #10234

Benchmark            (batchSize)  (batches)  (numContracts)  Mode  Cnt     Score     Error  Units
InsertBenchmark.run         1000          1            1000  avgt    5   336.674 ±  42.058  ms/op
InsertBenchmark.run         1000          3            1000  avgt    5   787.086 ± 223.018  ms/op
InsertBenchmark.run         1000          5            1000  avgt    5  1181.041 ± 317.017  ms/op
InsertBenchmark.run         1000          7            1000  avgt    5  1531.185 ± 341.060  ms/op
InsertBenchmark.run         1000          9            1000  avgt    5  1945.345 ± 436.352  ms/op

Score should ideally be more or less constant but it goes up very
significantly as the total ACS size changes

fixes #10245

changelog_begin
changelog_end
cocreature added a commit that referenced this issue Jul 14, 2021
Unfortunately the results seem to match up with my initial benchmark
in #10234

Benchmark            (batchSize)  (batches)  (numContracts)  Mode  Cnt     Score     Error  Units
InsertBenchmark.run         1000          1            1000  avgt    5   336.674 ±  42.058  ms/op
InsertBenchmark.run         1000          3            1000  avgt    5   787.086 ± 223.018  ms/op
InsertBenchmark.run         1000          5            1000  avgt    5  1181.041 ± 317.017  ms/op
InsertBenchmark.run         1000          7            1000  avgt    5  1531.185 ± 341.060  ms/op
InsertBenchmark.run         1000          9            1000  avgt    5  1945.345 ± 436.352  ms/op

Score should ideally be more or less constant but it goes up very
significantly as the total ACS size changes

fixes #10245

changelog_begin
changelog_end
cocreature added a commit that referenced this issue Jul 14, 2021
* Add a benchmark for contract insertion in the JSON API

Unfortunately the results seem to match up with my initial benchmark
in #10234

Benchmark            (batchSize)  (batches)  (numContracts)  Mode  Cnt     Score     Error  Units
InsertBenchmark.run         1000          1            1000  avgt    5   336.674 ±  42.058  ms/op
InsertBenchmark.run         1000          3            1000  avgt    5   787.086 ± 223.018  ms/op
InsertBenchmark.run         1000          5            1000  avgt    5  1181.041 ± 317.017  ms/op
InsertBenchmark.run         1000          7            1000  avgt    5  1531.185 ± 341.060  ms/op
InsertBenchmark.run         1000          9            1000  avgt    5  1945.345 ± 436.352  ms/op

Score should ideally be more or less constant but it goes up very
significantly as the total ACS size changes

fixes #10245

changelog_begin
changelog_end

* throughput -> average time

changelog_begin
changelog_end
@cocreature
Copy link
Contributor Author

This is mostly fixed by #10285, we still seem to pay a constant factor but I haven’t done a detailed investigation. Seems something like 2x. Maybe worth considering at some point but not for now.

@stefanobaghino-da stefanobaghino-da added component/json-api HTTP JSON API team/ledger-clients Related to the Ledger Clients team's components. labels Aug 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/json-api HTTP JSON API team/ledger-clients Related to the Ledger Clients team's components.
Projects
None yet
Development

No branches or pull requests

2 participants