Build real-time apps (Blazor included) with less than 1% of extra code responsible for real-time updates. Host 10-1000x faster APIs relying on transparent and nearly 100% consistent caching. We call it DREAM, or Distributed REActive Memoization, and it's here to turn real-time on!
MIT License
1.82k
stars
106
forks
source link
Compared performance to gRPC with heavy payloads #674
Firstly, thanks for your invested efforts and the openly publishing of your library.
This "issue" isn't really an issue, it's more like a conversation :)
My team and I are interested in alternative to gRPC such as your library and with the claimed performance improvement, it looked very promising.
However, I played a bit with your benchmark and found that with heavier load (10kB and 100kB) Slt.Fusion performs worse than gRPC on my machine (the payload is just a constant random string) whereas it's a known weakness of gRPC.
Hey 👋🏻
Firstly, thanks for your invested efforts and the openly publishing of your library. This "issue" isn't really an issue, it's more like a conversation :)
My team and I are interested in alternative to gRPC such as your library and with the claimed performance improvement, it looked very promising.
However, I played a bit with your benchmark and found that with heavier load (10kB and 100kB) Slt.Fusion performs worse than gRPC on my machine (the payload is just a constant random string) whereas it's a known weakness of gRPC.
Light is 1kB, Medium is 10kB and Heavy is 100kB.
Do you observe similar relative numbers? Am I doing something wrong?
Regards