[lovelle]

There makes no sense to comparing goroutines with os threads, they are totally different things, this is like comparing apples with oranges, of course both of them can be used to solve the same problem, but they are totally different. Like others have mentioned, is well known that a thread-per-connection solution does not scale well, a quite better approach is having a pool of threads with fixed size and using an asynchronous non-blocking event driven model. Actually in our company we did some benchmark messuring golang (1.9 with well known http servers) and java 8 with Netty, and the latter always won.

[anothergoogler]

What does "won" mean here? Better throughput? Lower latency? Less variance in latency? Better efficiency? re: the last one, I'd be shocked if Netty could match Go stdlib http in memory usage even if you benchmarked higher throughput. I'd expect the Go server to have lower variance too due to its GC design.

[lovelle]

Yes, this sentence is quite vague and does not give proper info about the topic, you only have to believe me or not, I'm not writing any blog about this, sorry.

Means higher throughput with lower jitter, that in our case was what we were looking at that time. For go defense we were using PooledByteBufAllocator for recycle Output Streams but memory usage was not a concern in benchmark as much as GC does not affect throughput. But I also believe that go http stdlib memory usage is better than netty, sorry for not being more helpful with this topic.

[anothergoogler]

Thanks for going into more detail, I'm interested that you got lower jitter. My experience with high performance JVM networking stacks is that they achieve incredible throughput but are quite hungry (with a hungry baseline too) and that 99P can be not so great due to GC. I'll have to give Netty another look. I'd be interested in the RSS of each process after warmup.

[lovelle]

In my experience tunning a jvm application in order to gain better throughput is far from a trivial job, although jvm ecosystem's requires a much more experienced developer on the platform to reach some levels in comparison to go simplicity which results in really high performance solution easier. For instance deciding an appropriate concurrent algorithms and measuring it. e.g. using AtomicInteger vs a per-thread-counter-based is not easy (specially in more complicated scenarios)

We have both java8 and go, high throughput critical microservices with excellent 99pctl, and in general memory is not a concern (as much as we do fine tuning on gc and don't have any memory leak) and generally for the really critical and portable solutions we choose java over go (unit testing and library versatility is a big player in this discussion)

[cryptonector]

It does make sense. These are all techniques for dealing with async events (I/O). Thread-per-client, cooperative multitasking / co-routines with co-routine-per-client, ... all the way to C10K-style thread-per-CPU callback hell.

[lovelle]

As I said both can be used to solve the same problem, but since they are totally different and works very different, to me it makes no sense doing a comparison and expecting similar results, if comparision's were analyzing the same technique in different languages then this will be fare.