support wait conn on busy

[king526]

support wait conn on busy ,it is aim at avoid make too much conns which i think will make performance problem. thanks for reviewing and i had make same change.

func (c *HostClient) releaseConn(cc *clientConn) {
	c.connsLock.Lock()
	c.conns = append(c.conns, cc)
	c.connsLock.Unlock()
	select {
	case c.connNotify <- struct{}{}:
	default:
	}
}

i do not think lost notify will cause problem. waiting is no guarantee on continuous heavy requests.it is crop traffic on a time bucket (timeout) not for make requests ordered .

[king526]

on my first version.i just wait util get a new conns which no use time.After. i think it's efficient but not sure if it is rational.

[king526]

i think that ci has bug?

[king526]

new commit is submited

[king526]

beated by the travis-ci, i am out.

[erikdubbelboer]

Sorry I'm currently working on some changes that will make our travis-ci build more stable. Just ignore it for now. I'll have time this weekend to look at your pull request!

[erikdubbelboer]

Thank you for the changes. I have a couple more requests.

[erikdubbelboer]

I don't really like this implementation. This way if a conn doesn't free up before the deadline we still have to wait for one to free up before we continue here. So we might be waiting much longer than our timeout.

[king526]

i will reconsider the implementation, there can be a better choose. since timer is inefficiency, i made this choose because it will not blocking api ,since we certainly use DoTimeout rather than Do. in our ad serving,5120 conns is set but sometime it still get a lot of no free conns error at monment.i do think it's necessary to take a action.

[erikdubbelboer]

You could just select between c.connNotify and a timer that signals at deadline (using AcquireTimer).

[erikdubbelboer]

I would prefer that instead of adding this field to ʼRequestʼ you add an extra parameter to ʼdoNonNilReqRespʼ etc.

[erikdubbelboer]

Nice test. But can it also work with a bit shorter times? Maybe tens of milliseconds instead of seconds. That way our test suite doesn't take that long.

[king526]

ci should take this bag

[erikdubbelboer]

I don't understand? People making changes to fasthttp will run go test locally and having to wait an extra 3 seconds for this is very annoying. The test should work just as fine if this was time.Millisecond * 30 and below time.Millisecond * 100.

[erikdubbelboer]

This loop does only one iteration so it can be removed.

[erikdubbelboer]

Suggested change

	err2 := waitClient.DoTimeout(req, nil, time.Second*10)
	err := waitClient.DoTimeout(req, nil, time.Second*10)

[erikdubbelboer]

Superseded by #764