During the afternoon we tested each of the 3 designs against a standard “out of the box” config – this ran on a single 4-way biztalk box and a super fast sql box. As a recap, the following are the designs
Async Design – designed to return processing to the payment flow asap, by launching the final accounting writes and summarisation as an async orchestration.
All in one – this design complete the entire process in a single synchronous orchestration – all processing is completed before returning to the payment flow.
Dispatch Message – this design completes the final accounting in a similar way to the Async design, but rather than call the orchestration using a “start”, a message is dispatched as a trigger.
Our initial tests were all based around 10,000 payments in a single file, on a single biztalk box. A harness was built around BAM to extract timings based on the number of accounting message posted between the first payment BAM activity and the last accounting BAM activity being written. This benchmark takes out the “loading” of the messagebox with the payment messages and so gives us a purer “throughput” figure (it also took account of the buffered BAM writing)
During the day we saw a number of problems with rules engines timeouts. Config changes were made to increase translation timeouts and also increase the rules policy cache. We also made some changes to the code that instantiates and executes the policy to improve its use of the cache – this improved performance. We saw significant troughs of performance during what looked like the rules loading. Darren took a number of dumps and these were sent to the US to review.
Our day 1 tests started on 1 box showed performance ranging from 28 to 120 accounting entries per second. The best performing design was the “all in one” at this point, with 120 aeps (accounting entries per second) on a singe box and 169 on a two box config.