5 ms·
The result is pretty impressive. Go's scheduler is not this good. When my Go GRPC servers get up near 100,000 RPS their profiles are totally dominated by `run
by jumpingmice 7y ago
The result is pretty impressive. Go's scheduler is not this good. When my Go GRPC servers get up near 100,000 RPS their profiles are totally dominated by `runqsteal` and `findrunnable`.
- typical182 7y agoProbably worth filing an issue, if you haven’t already? Some chance you might be hitting some pathological behavior that could be fixed or tweaked.
- hu3 7y agoWeird. In one of my Go explorations I wrote a naive trade algo backtracker which ingested 100,000 datapoints per second from SQLite on commodity hardware. I'd expect something highly specialized such as GRPC server to perform better.
- tozeur 7y agoHow did Go perform compared to a language like python? I thought the db would be the bottleneck?
- hu3 7y agoPython is awesome. It's fast as long you're mosty calling libraries. Not so fast if Python itself is doing most of the work.
- jumpingmice 7y agoReading 100k rows per second from sqlite sounds WAY easier than serving 100k HTTP/2 queries in the same time.
- hu3 7y agoTrue. But in my case the code also distributes these datapoints to multiple threads, computes technical indicators and simulates tradings while gathering statistics to finetunne parameters. The only optimization I've done was to ditch maps wherever I could. They were dominating flamegraphs. This is why I expected GRPC to perform better. But I agree it depends heavily on what's being done.