3.5x slowdown, considering you’ve removed all network latency, sounds reasonable to me.

This bug is also a bit too vague to be actionable.

It's also somewhat of a dup of more specific bugs #21525, #22809, #20058, #19840, #22807, #22806, #20967, and a dozen others.

I'm going to close this one, but feel free to file other specific issues.

@bradfitz Yes, this was more a question than a bug. I found some others issues like those you mentionned, but most of them talk about tls handshake, which, i think is a problem with many small https request. In this case, the requests fetch 100 MB of data each time. Some of them talk about arm64 architecture which is not relevant in this case.

@davecheney Thks for the answer. I tought the slowdown will be of few percent (many blog post on the net seems to show that), but i was wrong.

@davecheney Thks for the answer. I tought the slowdown will be of few percent (many blog post on the net seems to show that), but i was wrong.

once network latency is added, I expect the benchmarks would show a smaller difference.

Hi,
I have a very simple code which retrieve one metric from aws clouwatch with the aws go sdk :

svc := cloudwatch.New(session.New(), &aws.Config{Region: aws.String(region)})
        dur, _ := time.ParseDuration("300s")
        params := &cloudwatch.GetMetricStatisticsInput{
                StartTime:  aws.Time(time.Now().Add(-dur)), // Required
                EndTime:    aws.Time(time.Now()),           // Required
                MetricName: aws.String(metric_name),        // Required
                Namespace:  aws.String("AWS/ELB"),          // Required
                Period:     aws.Int64(300),                 // Required
                Statistics: []*string{ // Required
                        aws.String(metric_stat), // Required
                },
                Dimensions: []*cloudwatch.Dimension{
                        { // Required
                                Name:  aws.String("LoadBalancerName"), // Required
                                Value: aws.String(elb_name),           // Required
                        },
                },
                //Unit: aws.String("Count"),
        }
        resp, err := svc.GetMetricStatistics(params)

until now I compiled the program with go 1.8 and it works very fine :

time ./elb-check.go187 eu-west-1 test-elb Latency Average
{
Datapoints: [{
Average: 0.15102177378775059,
Timestamp: 2018-02-20 11:01:00 +0000 UTC,
Unit: "Seconds"
}],
Label: "Latency"
}

real 0m0.057s
user 0m0.028s
sys 0m0.008s

But now I upgraded my go package to 1.9, I noticed that time execution increased to more than 2x compared to 1.8 binary without any change in the code :

time ./elb-check.go19 eu-west-1 test-elb Latency Average
{
Datapoints: [{
Average: 0.15102177378775059,
Timestamp: 2018-02-20 11:01:00 +0000 UTC,
Unit: "Seconds"
}],
Label: "Latency"
}

real 0m0.123s
user 0m0.104s
sys 0m0.000s

the cpu consumption is also higher, I suspect the overhead comes from the SSL support in go 1.9 performed to cloudwatch to get the elb metric in my case.

Here is the pdf from pprof for 1.8 version :
out-go18.pdf

and here is the pdf for 1.10 version :
out-go110.pdf

it seems that the crypto part on new version makes much more syscall (and I/O operations) than the 1.8 version

@xp-1000, this issue is closed and thus is not tracked.

my bad @bradfitz I thought it will be better to add information to existing issue and reopen it instead of open a new one.