[go-nuts] Re: database/sql: Latency when calling DB.QueryContext()

[Kai Zhang]

Thanks for the reply.
 

> I don't think this has anything to do with the Context method variants or 
> Context related code.
>

Yes, the DB.Query() method also has this problem. 

This is just two different checks. One when the connection is returned, one 
> periodically. You seemed to say this was introducing latency. Can you make 
> some benchmarks with a real driver, one with the normal code and one with 
> the sync check commented out?


I found this problem when implement a sql driver for our private mysql 
proxy. Before disconnect from the proxy, the client need to send a message 
and wait for server reply.
I do this in driver.Close() method. That may block an online query request 
if the close operation in the synchronous check.
It happended frequently if  SetConnMaxLifetime() to a short duration, for 
example, 3 seconds. 

I also notice that in the mysql dirver 
(https://github.com/go-sql-driver/mysql), it will send packet to mysql 
server during driver.Close().  
https://github.com/go-sql-driver/mysql/blob/master/connection.go#L100
 97 func (mc *mysqlConn) Close() (err error) {
  98 // Makes Close idempotent
  99 if !mc.closed.IsSet() {
* 100 err = mc.writeCommandPacket(comQuit) 

   *
 101 }
 102 
 103 mc.cleanup()
 104 
 105 return
 106 }


I will do a benchmark for the mysql driver later. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Why copy is much slower than append when clone a slice?

[Keith Randall]

On Thu, Jun 29, 2017 at 12:04 PM, notcarl via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> If Element was a pointer type, it would need to zero it first though,
> right?
>
>
Yes, the don't-bother-zeroing optimization can only be done for pointerless
types.


>
> On Tuesday, June 27, 2017 at 8:11:01 PM UTC-7, Keith Randall wrote:
>>
>> This looks like it is all due to the extra zeroing required for the Copy
>> test.  CloneWithAppend does not need to zero the newly allocated slice
>> before copying the contents of x into it.  CloneWithCopy does.
>>
>> Benchmark_CloneWithAppend-4  3000480247 ns/op
>> Benchmark_CloneWithCopy-41000   1109543 ns/op
>>
>> If I hack the runtime to remove the no-zeroing-on-append optimization,
>> the performance difference disappears (it actually reverses):
>>
>> Benchmark_CloneWithAppend-4  1000   1443989 ns/op
>> Benchmark_CloneWithCopy-41000   1161912 ns/op
>>
>> I'm actually quite surprised that the differences seen here are so
>> large.  I don't understand how it can be more than a factor of 2.  Zeroing
>> should be no more expensive than copying.
>> If anyone has any idea why, let me know.
>>
>>
>> On Tuesday, June 27, 2017 at 7:04:33 PM UTC-7, Kevin Malachowski wrote:
>>>
>>> Hit send too early... Your benchmarks do show that something is strange
>>> hen comparing the make (memclr) and copy (memory copy) cases. Out of my
>>> element here :)
>>>
>>> On Jun 27, 2017 7:01 PM, "Kevin Malachowski"  wrote:
>>>
 But memclr+copy is slower than just copy, right?

 On Jun 27, 2017 6:53 PM, "T L"  wrote:

>
>
> On Tuesday, June 27, 2017 at 8:55:48 PM UTC-4, Kevin Malachowski wrote:
>>
>> It's best to compare the assembly, but my guess: 'make' has to zero
>> out the memory, whereas allocation using append does not.
>
>
> allocation using append will copy each element, which should be slower
> than memclr.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/golang-nuts/nDYYHKwvYhQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
 --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/nDYYHKwvYhQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Why copy is much slower than append when clone a slice?

[notcarl via golang-nuts]

If Element was a pointer type, it would need to zero it first though, right?

On Tuesday, June 27, 2017 at 8:11:01 PM UTC-7, Keith Randall wrote:
>
> This looks like it is all due to the extra zeroing required for the Copy 
> test.  CloneWithAppend does not need to zero the newly allocated slice 
> before copying the contents of x into it.  CloneWithCopy does.
>
> Benchmark_CloneWithAppend-4  3000480247 ns/op
> Benchmark_CloneWithCopy-41000   1109543 ns/op
>
> If I hack the runtime to remove the no-zeroing-on-append optimization, the 
> performance difference disappears (it actually reverses):
>
> Benchmark_CloneWithAppend-4  1000   1443989 ns/op
> Benchmark_CloneWithCopy-41000   1161912 ns/op
>
> I'm actually quite surprised that the differences seen here are so large. 
>  I don't understand how it can be more than a factor of 2.  Zeroing should 
> be no more expensive than copying.
> If anyone has any idea why, let me know.
>
>
> On Tuesday, June 27, 2017 at 7:04:33 PM UTC-7, Kevin Malachowski wrote:
>>
>> Hit send too early... Your benchmarks do show that something is strange 
>> hen comparing the make (memclr) and copy (memory copy) cases. Out of my 
>> element here :) 
>>
>> On Jun 27, 2017 7:01 PM, "Kevin Malachowski"  wrote:
>>
>>> But memclr+copy is slower than just copy, right?
>>>
>>> On Jun 27, 2017 6:53 PM, "T L"  wrote:
>>>


 On Tuesday, June 27, 2017 at 8:55:48 PM UTC-4, Kevin Malachowski wrote:
>
> It's best to compare the assembly, but my guess: 'make' has to zero 
> out the memory, whereas allocation using append does not.


 allocation using append will copy each element, which should be slower 
 than memclr.

 -- 
 You received this message because you are subscribed to a topic in the 
 Google Groups "golang-nuts" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/golang-nuts/nDYYHKwvYhQ/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 golang-nuts...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: database/sql: Latency when calling DB.QueryContext()

[Daniel Theophanes]

I don't think this has anything to do with the Context method variants or 
Context related code.

This is just two different checks. One when the connection is returned, one 
periodically. You seemed to say this was introducing latency. Can you make 
some benchmarks with a real driver, one with the normal code and one with 
the sync check commented out?

Thanks, -Daniel

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why copy is much slower than append when clone a slice?

[homemadepicklesrgood]

this simplified group of files show the same anomaly: 
https://gist.github.com/homemadepicklesaregood/fc25f3f7bf294bb919a8f8d2986d0d87

those knowing the internals of the introduced calls(growslice, slicepanic) 
within clone1.s should be able to pin point the cause. there also seems to 
be a bit more bookkeeping happening within clone1.s

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: json unmarshling error > cannot unmarshal object into Go struct field ParticipantIty.Player of type []utils.Playe

[suburb4nfilth]

That was it, i had a few more errors of the same type with other structs, 
but then i followed your advice and everything works now. Thank you!

On Thursday, June 29, 2017 at 3:42:24 PM UTC+3, C Banning wrote:
>
> Try:
>
>> type ParticipantIty struct {
>>  ParticipantId int
>> PlayerPlayer
>> }
>>
>
> On Thursday, June 29, 2017 at 6:10:03 AM UTC-6, Martin Spasov wrote:
>>
>> Hey guys,
>>
>> I have been trying to decode a json object into a struct with nested 
>> structs. When the struct is 1 level deep it does not create problems, but 
>> if i have a struct with an attribute that is a struct i get the error 
>> present in the title. Here is part of the code :
>>
>> Json :
>>
>> {
>> "seasonId": 8,
>> "queueId": 420,
>> "gameId": 3239663966,
>> "participantIdentities": [
>> {
>> "player": {
>> "currentPlatformId": "EUW1",
>> "summonerName": "MineManuDeYutu",
>> "matchHistoryUri": 
>> "/v1/stats/player_history/EUW1/219194561",
>> "platformId": "EUW1",
>> "currentAccountId": 219194561,
>> "profileIcon": 1666,
>> "summonerId": 68726031,
>> "accountId": 219194561
>> },
>> "participantId": 1
>> },
>> {
>> "player": {
>> "currentPlatformId": "EUW1",
>> "summonerName": "Just Deadly",
>> "matchHistoryUri": 
>> "/v1/stats/player_history/EUW1/205050256",
>> "platformId": "EUW1",
>> "currentAccountId": 205050256,
>> "profileIcon": 1666,
>> "summonerId": 47317494,
>> "accountId": 205050256
>> },
>> "participantId": 2
>> },
>> {
>> "player": {
>> "currentPlatformId": "EUW1",
>> "summonerName": "CougarHunting",
>> "matchHistoryUri": 
>> "/v1/stats/player_history/EUW1/36397748",
>> "platformId": "EUW1",
>> "currentAccountId": 36397748,
>> "profileIcon": 1666,
>> "summonerId": 32741461,
>> "accountId": 36397748
>> },
>> "participantId": 3
>> },
>> {
>> "player": {
>> "currentPlatformId": "EUW1",
>> "summonerName": "Loca111",
>> "matchHistoryUri": 
>> "/v1/stats/player_history/EUW1/231580371",
>> "platformId": "EUW1",
>> "currentAccountId": 231580371,
>> "profileIcon": 1665,
>> "summonerId": 96106805,
>> "accountId": 231580371
>> },
>> "participantId": 4
>> },
>> {
>> "player": {
>> "currentPlatformId": "EUW1",
>> "summonerName": "BoostedRiven420",
>> "matchHistoryUri": 
>> "/v1/stats/player_history/EUW1/231287442",
>> "platformId": "EUW1",
>> "currentAccountId": 231287442,
>> "profileIcon": 1665,
>> "summonerId": 95496854,
>> "accountId": 231287442
>> },
>> "participantId": 5
>> },
>> {
>> "player": {
>> "currentPlatformId": "EUW1",
>> "summonerName": "Hroom",
>> "matchHistoryUri": 
>> "/v1/stats/player_history/EUW1/217895755",
>> "platformId": "EUW1",
>> "currentAccountId": 217895755,
>> "profileIcon": 1665,
>> "summonerId": 66941009,
>> "accountId": 217895755
>> },
>> "participantId": 6
>> },
>> {
>> "player": {
>> "currentPlatformId": "EUW1",
>> "summonerName": "Nyss3",
>> "matchHistoryUri": 
>> "/v1/stats/player_history/EUW1/22525212",
>> "platformId": "EUW1",
>> "currentAccountId": 22525212,
>> "profileIcon": 1665,
>> "summonerId": 19693763,
>> "accountId": 22525212
>> },
>> "participantId": 7
>> },
>> {
>> "player": {
>> "currentPlatformId": "EUW1",
>> "summonerName": "Number2333",
>> "matchHistoryUri": 
>> "/v1/stats/player_history/EUW1/225600988",
>> "platformId": "EUW1",
>> "currentAccountId": 225600988,
>> "profileIcon": 1665,
>> "summonerId": 82017867,
>> "accountId": 225600988
>> },
>> "participantId": 8
>> },
>> {
>> "player": {
>> "currentPlatformId": "EUW1",
>> "summonerName": "Asianpowerbabe",
>> 

[go-nuts] can you point me in the direction of some well designed restful apis built in golang?

[Eoin Ahern]

hi Guys,
I was wondering if you can you point me in the direction of 
some well designed restful apis build in golang ? Ive already built a small 
restful api with golang. it works but its small scale toy project. I would 
like to look at a few open source api's built with golang that use proper 
design, security, testing etc. just to steal a few ideas :) . thanks, your 
help is really appreciated. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: json unmarshling error > cannot unmarshal object into Go struct field ParticipantIty.Player of type []utils.Playe

[C Banning]

Try:

> type ParticipantIty struct {
>  ParticipantId int
> PlayerPlayer
> }
>

On Thursday, June 29, 2017 at 6:10:03 AM UTC-6, Martin Spasov wrote:
>
> Hey guys,
>
> I have been trying to decode a json object into a struct with nested 
> structs. When the struct is 1 level deep it does not create problems, but 
> if i have a struct with an attribute that is a struct i get the error 
> present in the title. Here is part of the code :
>
> Json :
>
> {
> "seasonId": 8,
> "queueId": 420,
> "gameId": 3239663966,
> "participantIdentities": [
> {
> "player": {
> "currentPlatformId": "EUW1",
> "summonerName": "MineManuDeYutu",
> "matchHistoryUri": 
> "/v1/stats/player_history/EUW1/219194561",
> "platformId": "EUW1",
> "currentAccountId": 219194561,
> "profileIcon": 1666,
> "summonerId": 68726031,
> "accountId": 219194561
> },
> "participantId": 1
> },
> {
> "player": {
> "currentPlatformId": "EUW1",
> "summonerName": "Just Deadly",
> "matchHistoryUri": 
> "/v1/stats/player_history/EUW1/205050256",
> "platformId": "EUW1",
> "currentAccountId": 205050256,
> "profileIcon": 1666,
> "summonerId": 47317494,
> "accountId": 205050256
> },
> "participantId": 2
> },
> {
> "player": {
> "currentPlatformId": "EUW1",
> "summonerName": "CougarHunting",
> "matchHistoryUri": 
> "/v1/stats/player_history/EUW1/36397748",
> "platformId": "EUW1",
> "currentAccountId": 36397748,
> "profileIcon": 1666,
> "summonerId": 32741461,
> "accountId": 36397748
> },
> "participantId": 3
> },
> {
> "player": {
> "currentPlatformId": "EUW1",
> "summonerName": "Loca111",
> "matchHistoryUri": 
> "/v1/stats/player_history/EUW1/231580371",
> "platformId": "EUW1",
> "currentAccountId": 231580371,
> "profileIcon": 1665,
> "summonerId": 96106805,
> "accountId": 231580371
> },
> "participantId": 4
> },
> {
> "player": {
> "currentPlatformId": "EUW1",
> "summonerName": "BoostedRiven420",
> "matchHistoryUri": 
> "/v1/stats/player_history/EUW1/231287442",
> "platformId": "EUW1",
> "currentAccountId": 231287442,
> "profileIcon": 1665,
> "summonerId": 95496854,
> "accountId": 231287442
> },
> "participantId": 5
> },
> {
> "player": {
> "currentPlatformId": "EUW1",
> "summonerName": "Hroom",
> "matchHistoryUri": 
> "/v1/stats/player_history/EUW1/217895755",
> "platformId": "EUW1",
> "currentAccountId": 217895755,
> "profileIcon": 1665,
> "summonerId": 66941009,
> "accountId": 217895755
> },
> "participantId": 6
> },
> {
> "player": {
> "currentPlatformId": "EUW1",
> "summonerName": "Nyss3",
> "matchHistoryUri": 
> "/v1/stats/player_history/EUW1/22525212",
> "platformId": "EUW1",
> "currentAccountId": 22525212,
> "profileIcon": 1665,
> "summonerId": 19693763,
> "accountId": 22525212
> },
> "participantId": 7
> },
> {
> "player": {
> "currentPlatformId": "EUW1",
> "summonerName": "Number2333",
> "matchHistoryUri": 
> "/v1/stats/player_history/EUW1/225600988",
> "platformId": "EUW1",
> "currentAccountId": 225600988,
> "profileIcon": 1665,
> "summonerId": 82017867,
> "accountId": 225600988
> },
> "participantId": 8
> },
> {
> "player": {
> "currentPlatformId": "EUW1",
> "summonerName": "Asianpowerbabe",
> "matchHistoryUri": 
> "/v1/stats/player_history/EUW1/204195645",
> "platformId": "EUW1",
> "currentAccountId": 204195645,
> "profileIcon": 1665,
> "summonerId": 45862904,
> "accountId": 204195645
> },
> "participantId": 9
> },
>   

[go-nuts] Re: Go 1.9 Beta 2 is released

[alb . donizetti]

But if you have other numbers please share them, it'll certainly interesing
to see them.

Il giorno giovedì 29 giugno 2017 13:38:18 UTC+2, Parker Evans ha scritto:
>
> Congratulations on the Beta 2 release, pretty excited to test it out. 
>  Lots of interesting updates!
>
> I did notice one thing when I was playing around with Beta 1 and now Beta 
> 2 that I wanted to ask about.  Is it expected that binary size would 
> increase in this release?  A toy example that has been somewhat of a 
> benchmark in previous releases is the simple hello world program:
>
> package main
>
> import (
>
>   "fmt"
>
> )
>
>
> func main() {
>
>fmt.Println("Hello world!")
>
> }
>
> It seems like this program, when compiled with options to strip debugging 
> information has grown about 20% in size when compiled natively for macOS:
>
> go version go1.8.3 darwin/amd64
>
> $ go build -ldflags="-w -s"
>
> $ ls -l
>
> total 2320
>
> -rw-r--r--  1 Parker  staff   79 Jun 16 18:47 main.go
>
> -rwxr-xr-x  1 Parker  staff  1181728 Jun 29 07:24 test
>
> go version devel +eab99a8 Mon Jun 26 21:12:22 2017 + darwin/amd64
>
> $ go build -ldflags="-w -s"
>
> $ ls -l
>
> total 2792
>
> -rw-r--r--  1 Parker  staff   79 Jun 16 18:47 main.go
>
> -rwxr-xr-x  1 Parker  staff  1424992 Jun 29 07:11 test
>
> Anyone have any insight on whether this is expected and if a similar 
> increase should be expected across the board in this release?
>
> Thanks,
> Parker
>
> On Monday, June 26, 2017 at 6:11:46 PM UTC-4, Chris Broadfoot wrote:
>>
>> Hello gophers,
>>
>> We have just released go1.9beta2, a beta version of Go 1.9.
>> It is cut from the master branch at the revision tagged go1.9beta2.
>>
>> There are no known problems or regressions.
>> Please try running production load tests and your unit tests with the new 
>> version.
>> Your help testing these pre-release versions is invaluable.
>>
>> Report any problems using the issue tracker:
>> https://golang.org/issue/new
>>
>> If you have Go installed already, the easiest way to try go1.9beta2
>> is by using this tool:
>> https://godoc.org/golang.org/x/build/version/go1.9beta2
>>
>> You can download binary and source distributions from the usual place:
>> https://golang.org/dl/#go1.9beta2
>>
>> To find out what has changed in Go 1.9, read the draft release notes:
>> https://tip.golang.org/doc/go1.9
>>
>> Documentation for Go 1.9 is available at:
>> https://tip.golang.org/
>>
>> Cheers,
>> Chris
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.9 Beta 2 is released

[alb . donizetti]

Unstripped "hello world"s are ~20% bigger on my Linux system too, but
it seems like the loss is much smaller on real programs, e.g. see Brad
comment here:

  https://github.com/golang/go/issues/6853#issuecomment-307155309

A.

Il giorno giovedì 29 giugno 2017 13:38:18 UTC+2, Parker Evans ha scritto:
>
> Congratulations on the Beta 2 release, pretty excited to test it out. 
>  Lots of interesting updates!
>
> I did notice one thing when I was playing around with Beta 1 and now Beta 
> 2 that I wanted to ask about.  Is it expected that binary size would 
> increase in this release?  A toy example that has been somewhat of a 
> benchmark in previous releases is the simple hello world program:
>
> package main
>
> import (
>
>   "fmt"
>
> )
>
>
> func main() {
>
>fmt.Println("Hello world!")
>
> }
>
> It seems like this program, when compiled with options to strip debugging 
> information has grown about 20% in size when compiled natively for macOS:
>
> go version go1.8.3 darwin/amd64
>
> $ go build -ldflags="-w -s"
>
> $ ls -l
>
> total 2320
>
> -rw-r--r--  1 Parker  staff   79 Jun 16 18:47 main.go
>
> -rwxr-xr-x  1 Parker  staff  1181728 Jun 29 07:24 test
>
> go version devel +eab99a8 Mon Jun 26 21:12:22 2017 + darwin/amd64
>
> $ go build -ldflags="-w -s"
>
> $ ls -l
>
> total 2792
>
> -rw-r--r--  1 Parker  staff   79 Jun 16 18:47 main.go
>
> -rwxr-xr-x  1 Parker  staff  1424992 Jun 29 07:11 test
>
> Anyone have any insight on whether this is expected and if a similar 
> increase should be expected across the board in this release?
>
> Thanks,
> Parker
>
> On Monday, June 26, 2017 at 6:11:46 PM UTC-4, Chris Broadfoot wrote:
>>
>> Hello gophers,
>>
>> We have just released go1.9beta2, a beta version of Go 1.9.
>> It is cut from the master branch at the revision tagged go1.9beta2.
>>
>> There are no known problems or regressions.
>> Please try running production load tests and your unit tests with the new 
>> version.
>> Your help testing these pre-release versions is invaluable.
>>
>> Report any problems using the issue tracker:
>> https://golang.org/issue/new
>>
>> If you have Go installed already, the easiest way to try go1.9beta2
>> is by using this tool:
>> https://godoc.org/golang.org/x/build/version/go1.9beta2
>>
>> You can download binary and source distributions from the usual place:
>> https://golang.org/dl/#go1.9beta2
>>
>> To find out what has changed in Go 1.9, read the draft release notes:
>> https://tip.golang.org/doc/go1.9
>>
>> Documentation for Go 1.9 is available at:
>> https://tip.golang.org/
>>
>> Cheers,
>> Chris
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.9 Beta 2 is released

[Parker Evans]

Congratulations on the Beta 2 release, pretty excited to test it out.  Lots 
of interesting updates!

I did notice one thing when I was playing around with Beta 1 and now Beta 2 
that I wanted to ask about.  Is it expected that binary size would increase 
in this release?  A toy example that has been somewhat of a benchmark in 
previous releases is the simple hello world program:

package main

import (

  "fmt"

)


func main() {

   fmt.Println("Hello world!")

}

It seems like this program, when compiled with options to strip debugging 
information has grown about 20% in size when compiled natively for macOS:

go version go1.8.3 darwin/amd64

$ go build -ldflags="-w -s"

$ ls -l

total 2320

-rw-r--r--  1 Parker  staff   79 Jun 16 18:47 main.go

-rwxr-xr-x  1 Parker  staff  1181728 Jun 29 07:24 test

go version devel +eab99a8 Mon Jun 26 21:12:22 2017 + darwin/amd64

$ go build -ldflags="-w -s"

$ ls -l

total 2792

-rw-r--r--  1 Parker  staff   79 Jun 16 18:47 main.go

-rwxr-xr-x  1 Parker  staff  1424992 Jun 29 07:11 test

Anyone have any insight on whether this is expected and if a similar 
increase should be expected across the board in this release?

Thanks,
Parker

On Monday, June 26, 2017 at 6:11:46 PM UTC-4, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We have just released go1.9beta2, a beta version of Go 1.9.
> It is cut from the master branch at the revision tagged go1.9beta2.
>
> There are no known problems or regressions.
> Please try running production load tests and your unit tests with the new 
> version.
> Your help testing these pre-release versions is invaluable.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.9beta2
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.9beta2
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.9beta2
>
> To find out what has changed in Go 1.9, read the draft release notes:
> https://tip.golang.org/doc/go1.9
>
> Documentation for Go 1.9 is available at:
> https://tip.golang.org/
>
> Cheers,
> Chris
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Canonical http upload code

[Kai Hendry]

Just to conclude since I accidentally went into a private conversation
with Dave, that a simple example here:
https://github.com/kaihendry/go-upload

Handles large uploads with ease. Something is amiss with
https://github.com/wmark/caddy.upload/issues/24 that I need to track
down, though I've got a great starting point.

So thanks!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: golang thrift server 28k/s request client many dial tcp timeout ,why??

[Kai Zhang]

May be reach the max file descriptor limit , when timeout occurred,  may 
check the output of following command on the server side
ss -lnt


On Thursday, June 8, 2017 at 11:58:55 PM UTC+8, 刘桂祥 wrote:
>
>I have a very simple golang thrift server. the handle is very easy 
> just to return
>But when I use another machine to benchmark the server ,when the 
> qps to 28K/s , client have many dial tcp io/timeout 
>I don't konw the reason ? is the client or server's problem? 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: golang thrift server 28k/s request client many dial tcp timeout ,why??

[Kai Zhang]

May be read max file descriptor limit , when timeout occurred,  may check 
the output of following command on the server side
ss -lnt


On Thursday, June 8, 2017 at 11:58:55 PM UTC+8, 刘桂祥 wrote:
>
>I have a very simple golang thrift server. the handle is very easy 
> just to return
>But when I use another machine to benchmark the server ,when the 
> qps to 28K/s , client have many dial tcp io/timeout 
>I don't konw the reason ? is the client or server's problem? 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] database/sql: Latency when calling DB.QueryContext()

[Kai Zhang]

Go version 1.8.3

In DB.QueryContext(), Go will close long live connection which exceeded the 
duration setted by  DB.SetConnMaxLifetime(), the code is below
database/sql/sql.go
 895 func (db *DB) conn(ctx context.Context, strategy connReuseStrategy) 
(*driverConn, error) {
 896 db.mu.Lock()
 897 if db.closed {
 898 db.mu.Unlock()
 899 return nil, errDBClosed
 900 }
 901 // Check if the context is expired.
 902 select {
 903 default:
 904 case <-ctx.Done():
 905 db.mu.Unlock()
 906 return nil, ctx.Err()
 907 }
 908 lifetime := db.maxLifetime
 909 
 910 // Prefer a free connection, if possible.
 911 numFree := len(db.freeConn)
 912 if strategy == cachedOrNewConn && numFree > 0 {
 913 conn := db.freeConn[0]
 914 copy(db.freeConn, db.freeConn[1:])
 915 db.freeConn = db.freeConn[:numFree-1]
 916 conn.inUse = true
 917 db.mu.Unlock()
* 918 if conn.expired(lifetime) {*
* 919 conn.Close()*
 920 return nil, driver.ErrBadConn
 921 } 

  
 922 return conn, nil
 923 }


The problem is if driver.Close() has some handshake to tear down the 
connection, this may introduce unexpected latency. But the driver.Conn 
interface not mention this.
database/sql/driver/driver.go
 143 type Conn interface {
 144 // Prepare returns a prepared statement, bound to this connection.
 145 Prepare(query string) (Stmt, error)
 146 
 147 // Close invalidates and potentially stops any current
 148 // prepared statements and transactions, marking this
 149 // connection as no longer in use.
 150 //
 151 // Because the sql package maintains a free pool of
 152 // connections and only calls Close when there's a surplus of
 153 // idle connections, it shouldn't be necessary for drivers to
 154 // do their own connection caching.   

  
 155 Close() error
 156 
 157 // Begin starts and returns a new transaction.
 158 //
 159 // Deprecated: Drivers should implement ConnBeginTx instead (or 
additionally).
 160 Begin() (Tx, error)
 161 }

There is already a goroutine to clean the connections, why still need a 
synchronous check? 
database/sql/sql.go
 750 func (db *DB) connectionCleaner(d time.Duration) { 

 
 751 const minInterval = time.Second
 752 
 753 if d < minInterval {
 754 d = minInterval
 755 }
 756 t := time.NewTimer(d)
 757 
 758 for {
 759 select {
 760 case <-t.C:
 761 case <-db.cleanerCh: // maxLifetime was changed or db was 
closed.
 762 }
 763 
 764 db.mu.Lock()
 765 d = db.maxLifetime
 766 if db.closed || db.numOpen == 0 || d <= 0 {
 767 db.cleanerCh = nil
 768 db.mu.Unlock()
 769 return
 770 }
 771 
 772 expiredSince := nowFunc().Add(-d)
 773 var closing []*driverConn
 774 for i := 0; i < len(db.freeConn); i++ {
 775 c := db.freeConn[i]
 776 if c.createdAt.Before(expiredSince) {
 777 closing = append(closing, c)
 778 last := len(db.freeConn) - 1
 779 db.freeConn[i] = db.freeConn[last]
 780 db.freeConn[last] = nil
 781 db.freeConn = db.freeConn[:last]
 782 i--
 783 }
 784 }



Is this by design or need to be fixed? 

-- 
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.
For more options, visit https://groups.google.com/d/optout.