|
The impression that I get about Go is that it's excellent at concurrency and bad at parallelism, somewhat like a strongly-typed NodeJS. Am I wrong? I've been looking for a chance to do some real work using Golang but the project I'm about to start has a serious need for parallel computation so I'm thinking I'll just try C# on .NET Core or Kotlin.
|
#
¿
Jun 27, 2017 17:16
|
|
|
|
| # ¿ May 5, 2024 18:51 |
|
|
skul-gun posted:I guess that depends on how you mean "bad at parallelism." Go programs aren't stuck to being single-threaded as with node. There is a setting (GOMAXPROCS) that controls how many OS threads can be used to execute goroutines. GOMAXPROCS used to default to 1, but now defaults to the logical number of CPUs. Well, thanks for opening my eyes guys. I had found some older documentation that indicated that GOMAXPROCS defaulted to 1 and best practice was to leave it there. I'm certainly more familiar with multithreaded C# / Java and using Goldman Sachs Collections from Kotlin looked like a simple solution, but I'm going to take a look at Go before I write it off.
|
|
#
¿
Jun 27, 2017 17:59
|
|
|
I'm having mysteriously bad HTTPS serving performance, specifically TLS handshakes. Real applications are using the http.ListenAndServeTLS, right? I profiled my application and... it's spending all of its time doing TLS handshakes on a simulated load that we believe represents realistic traffic. This is running on AWS, in ECS behind an ALB, but I'm under a contractual requirement to encrypt all traffic end to end, so the service needs its own self-signed cert. Any suggestions before I bolt on a sidecar proxy that will terminate SSL inside the same ECS task? That sounds like more headache than I want right now, and I'm disappointed that NodeJS seems to be able to TLS handshake significantly more efficiency than Go's built in http server. 
|
|
#
¿
Dec 15, 2019 03:07
|
|
|
All of this is helpful, thanks. I'll definitely move to an ECDSA key for the cert. I had read they were faster at some point, but didn't realize that optimizations on one path but not the other mean it's an order of magnitude. The other issue that I've noticed contributing is that the ALB is demuxing HTTP/2 connections onto a much higher number of HTTP/1.1 connections between ALB and backend. I hadn't read the docs yet, and assumed that "HTTP/2" support on ALBs meant both client-facing and backend, but it's client-facing only. I'm going to turn up the keep-alive timeout in hopes of re-using connections more often. The traffic to this is spiky, and the default 60s timeout isn't long enough. Twerk from Home fucked around with this message at 16:17 on Dec 15, 2019 |
|
#
¿
Dec 15, 2019 15:58
|
|