Use transaction batch instead of a stored procedure to improve performance

stevewgh commented 3 years ago

Overview

Removed appendToStream.js and replaced the appending code with TransactionBatch instead. Added a performance test to check the improvements of TransactionBatch. Removed AssemblyInfo from the repo debug folder which had been added in error in a previous commit

Performance Improvements

The statistics were generated by the performance test included in this PR (it's marked as ignored to improve CI/CD timing).
The test was run against a local emulator on a development machine
Each client is represented as an async task. Each task performs 40 stream writes. Each stream contains two events with each one written separately. Full details are within the PerformanceTest.cs file

Events written per second

Clients	Stored Procedure	Transaction Batch	% Improvement
25	230.25	286.02	24%
50	460.58	598.34	29%
75	669.39	887.60	32%
100	860.96	953.39	10% **

** this test only shows a minor performance improvement potentially because of hard limitations of the test machine. A distributed load test should be used to establish true performance gains but the 'like for like' test does show repeatable gains over the use of a stored procedure.

External Links

https://devblogs.microsoft.com/cosmosdb/introducing-transactionalbatch-in-the-net-sdk/

afscrome commented 3 years ago

Do you have a comparison of RU cost in addition to rps?

stevewgh commented 3 years ago

@afscrome using a free Cosmos account (limited to 400 RU's) I had to scale the test back considerably to get it to run but here's the results:

Type	Min RU	Max RU	Avg RU
Stored Procedure	8.57	12.06	9.36
Transaction Batch	7.24	8.24	7.74

So less RU's and more RPS's which kinda makes sense if you consider it an optimised operation server side.

ASOS / SimpleEventStore