A modern programming language that makes developers happier.

kotlinlang

I'm excited to announce my Kotlin Multiplatform <http://NATS.io|NATS.io> client, *NATS.kt*.
It is built on Ktor.
Core NATS features are available now, with JetStream in active development.

This was born out of pain trying to use NATS in multiplatform applications and needing to wrap each platform's client.

I'd appreciate a star to support development. I plan to donate the project to the NATS community (CNCF) once it reaches maturity.

<https://github.com/n-hass/nats.kt>

This is wonderful. How have you found the performance so far? We love nats. Its a very underappreciated project.

<@U04UNDEGHNC> I’ve done some preliminary profiling against the Java client. It’s actually far more CPU efficient (~60% of CPU time in comparison) thanks to being coroutine based - internally the Java client uses dispatchers which maybe spin-wait or something as I was surprised how slow (concurrent reads/writes over its socket) are, yet how hard it spikes the CPU.

I am aware you can very easily eat up memory though if you spam requests / received messages as, unlike the Java client, messages will be processed as fast as possible over the socket which will lead to higher instantaneous memory consumption to hold each message. There is perhaps better ways than allocating a ByteArray  per message recv. Or maybe this a feature, not a bug :)

My theory is the Java client would have this same issue as well if it were not as slow, but my test harness gives it a chance to drop a ByteArray from a previous and reuse its allocated space in the JVM heap without a system memory impact.

There is also some memory hit with synchronisation overhead of the socket. It’s not significant, could probably improve consumption 5% under heavy load, but it’s low hanging fruit.

Awesome...will have to dig in and check it out. You're probably already doing it but thinking buffered channels may help as well or something like a ring queue to allow throttling of the messages read into memory prior to processing, etc. That's a great explanation and makes a lot of sense. Great work my friend.

Thanks! Let me know what you think. Documentation is quite light right now, but the API is intuitive.

I had thought of a buffered channel for back pressure to slot in at the transport layer to replace the current synchronisation via mutex.