shubham1172
commented
9 months ago Hi @SumeetR, behind the scenes both the SDKs are making API calls to the runtime. Now generally speaking we are using node in the JS-SDK today and it can be less performant in this scenario than dotnet, for e.g., see https://raygun.com/blog/dotnet-vs-nodejs. If we test another SDK, say Go-SDK, we might see yet another performance metrics, which is to say we cannot strictly compare SDK performances which each other because of the difference in the underlying frameworks/stacks.
If you are looking to make concurrent calls to the state store, you could explore making Bulk API calls, this will significantly reduce the number of API calls and in-turn the overall memory consumed, you can see from the docs here https://docs.dapr.io/developing-applications/sdks/js/js-client/#save-get-and-delete-application-state
There was a noticeable difference in performance when pulling these docker images from a repository, compared to creating the docker image in-situ from the docker-compose file. Building in-situ in the EC2 machine produced similar results from both demo repositories, compared to pulling the image from our private repository.
If the Dockerfile(s) are the same, this should not happen, right? You could investigate the images further (with some tooling like https://github.com/wagoodman/dive) to check if there are differences in your images.
dapr-bot
Expected Behavior
The performance of the DAPR js-sdk should be comparable of that of the dotnet-sdk. More specifically, the performance of the State client of the SDKs should be similar.
Actual Behavior
The js-sdk consumes significantly more CPU when storing in the state than the dotnet-sdk.
In our project, we have a Typescript service and a .NET service, each using DAPR with their own sidecar, communicating through the DAPR pubsub and using the DAPR state to store information. All of this is deployed in docker containers.
When running tests we spotted that the typescript project was consuming a large chunk of the available CPU, around 50% of the available CPU. When isolating the issue, disabling writing to the state using DAPR dropped that CPU usage to 20%. The backing storage used is Redis for the state.
Steps to Reproduce the Problem
To exhibit this issue, we've created two repositories, one in Typescript and the other in .NET, which implement a simple API. These APIs expose a HTTP endpoint which stores the payload of the request using the DAPR state into Redis.
Typescript: https://github.com/dkuida/dapr-ts-performance
.NET: https://github.com/dkuida/dapr-dotnet-performance
A docker image was created using github actions for each repo and then tested by calling the HTTP POST endpoint of each API with a concurrency of 10 calls. The deployments were hosted on an AWS EC2 m5a.large machine:
Performance
Typescript
.NET
As the images above show, the Typescript version was consuming considerably more CPU throughout the test.
Observations
There was a noticeable difference in performance when pulling these docker images from a repository, compared to creating the docker image in-situ from the docker-compose file. Building in-situ in the EC2 machine produced similar results from both demo repositories, compared to pulling the image from our private repository.