As another data point, I decided to test a few implementations of http2 downloads on OSX.
Using a Go server with default frame size (16k): Go client: 900 M/s Java client: 1300 M/s curl: 1500 M/s Using a Java server with default frame size (16k): Go client: 670 M/s Java client: 720 M/s curl: 800 M/s Using Go server with 256k client max frame size: Go client: 2350 M/s Java client: 2800 M/s curl: unable to set option Using Java server with 256k client max frame size: Go client: 2900 M/s Java client: 2800 M/s curl: unable to set option Clearly using a Go based server is the way to go :) But there also seems to be an opportunity to improve the Go http2 client performance. > On Nov 10, 2021, at 8:33 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Wed, Nov 10, 2021 at 5:29 PM robert engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: > Hi, > > While investigating the http2 issue, I saw this in the profiler: (sorry for > the screenshot) > > <PastedGraphic-1.png> > > and looking at the code: > > func syscall_syscall(fn, a1, a2, a3 uintptr) (r1, r2, err uintptr) { > entersyscall() > libcCall(unsafe.Pointer(abi.FuncPCABI0(syscall)), unsafe.Pointer(&fn)) > exitsyscall() > return > } > > This is implies that the runtime overhead to make the system call - in > entersyscall() and exitsyscal() - is more than 10x the cost of doing the > actual call. > > Am I reading this right? If so, is there any outstanding issues to try and > optimize this? > > Btw, the call being performed is a simple write to a socket. > > I'm not sure I trust the profiling here: it's fairly likely that the time > required by the system call itself is not being correctly attributed. But > the general idea may be true: it does take time to record in the scheduler > that we are entering a system call. This is also why cgo calls are slow. > And, in fact, on macOS system calls are essentially cgo calls, because macOS > requires us to go through the C based libSystem rather than simply executing > a SYSCALL or SVC instruction. > > I don't know offhand whether there are any open issues for speeding up these > calls, and I couldn't find any in a quick search. People who work on the Go > runtime are well aware of the problem. > > Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVJqwMttzrE3GXeQf%2BC%3DKVtGFz%3DaXv%3DNXxaunWngE9L6Q%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVJqwMttzrE3GXeQf%2BC%3DKVtGFz%3DaXv%3DNXxaunWngE9L6Q%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/73CB6AC5-B9B7-4421-AD07-E54DB3E4B003%40ix.netcom.com.
