Description
Bug Report
I wrote a relatively simple code that creates a few go routines and sends batches with a number of inserts.
What caught my attention is that it seems as if the requests are being serialized.
The go routine looks like this:
go func(){
//(...) obtains client, etc, setups batch, etc.
start:=time.Now()
itemResponse, err:=containerClient.ExecuteTransactionalBatch(context.Background, batch, nil)
//(...)
log.Info().TimeDiff("elapsed-time", time.Now(), start).Msg("transaction ok")
}
If I start 100 of these go routines, the time keeps adding up. For instance, the first go routine takes 300ms, the second 540, the third 850, etc..
This is not definitely not what I would expect. It is as if something down the stack is serializing the actual requests, but I can't pinpoint what exactly.
After running a profiling session I see an inordinate amount of CPU spent on azcore/runtime.UnmarshalAsJson; that method definitely should be optimized, but I don't think that explains the problem I'm observing.
I also observe that there is a single HTTP connection opened to Azure but I guess this is expected given that HTTP2 is being used. Again, to me that doesn't explain what I'm observing.
This should be pretty easy to reproduce but I'm happy to share the code.
-->
what I'm importing:
github.com/Azure/azure-sdk-for-go v68.0.0+incompatible // indirect
github.com/Azure/azure-sdk-for-go/sdk/azcore v1.6.0 // indirect
github.com/Azure/azure-sdk-for-go/sdk/data/azcosmos v0.3.5 // indirect
github.com/Azure/azure-sdk-for-go/sdk/internal v1.3.0 // indirect
go version is 1.20.3
- import path of package in question, e.g.
.../services/compute/mgmt/2018-06-01/compute
- SDK version e.g.
master
,latest
,18.1.0
- Specify the exact commit if possible; one way to get this is the REVISION
column output bydep status "github.com/Azure/azure-sdk-for-go
.
- Specify the exact commit if possible; one way to get this is the REVISION
- output of
go version