Closed tsenart closed 9 years ago
Great, thanks! I'll test this change on Monday to see how much it impacts performance. I suspect this is not the major cause of slowdown for the Go code though. It seems like something more fundamental is wrong...
We could easily profile one of these tests and see where the bottleneck is.
I profiled it a while ago, and the main culprit was epollwait
. Unfortunately, that doesn't help us much in terms of improving the performance.. I'll check again with your merged changes on Monday.
Hmm, the performance improvement appears to be fairly marginal:
I'll merge the changes regardless, and post profiling results in servers/go/profile.svg
.
I have the theory that by increasing the number of OS threads that the Go scheduler can run on, we'll get better results.
The GOMAXPROCS variable limits the number of operating system threads that can execute user-level Go code simultaneously. There is no limit to the number of threads that can be blocked in system calls on behalf of Go code; those do not count against the GOMAXPROCS limit. This package's GOMAXPROCS function queries and changes the limit.
On Monday, June 15, 2015, Jon Gjengset notifications@github.com wrote:
Merged #1 https://github.com/jonhoo/volley/pull/1.
— Reply to this email directly or view it on GitHub https://github.com/jonhoo/volley/pull/1#event-331331155.
Sent from Gmail Mobile
I'm not sure what you mean. Since there is no limit to the number of threads Go can have blocking in system calls at any given point in time, Go should presumably manage this on its own? The best we can do is set GOMAXPROCS
to an appropriate value. Are you proposing we increase the value of GOMAXPROCS
further?
Yes, that's what I'm proposing, for the sake of experimentation. It'd also be nice to know what version of Go is being used.
$ go version
go version go1.4.1 linux/amd64
I'll run a benchmark with a higher GOMAXPROCS
and see if it makes a difference. Could you open a ticket for this so we can continue the discussion there? Please also link back to this PR from the ticket.
I'll do that tomorrow as I'm limited to a mobile phone until then.
On Monday, June 15, 2015, Jon Gjengset notifications@github.com wrote:
$ go version go version go1.4.1 linux/amd64
I'll run a benchmark with a higher GOMAXPROCS and see if it makes a difference. Could you open a ticket for this so we can continue the discussion there? Please also link back to this PR from the ticket.
— Reply to this email directly or view it on GitHub https://github.com/jonhoo/volley/pull/1#issuecomment-112195877.
Sent from Gmail Mobile
Never mind, I filed it as #2.
This change set improves the Go server performance by reducing memory allocations and not relying on run-time reflection which the binary.{Read,Write} functions use under the hood.