dyweb / cloudab Goto Github PK

Ref https://jira.mongodb.org/browse/GODRIVER-1884
Ref https://jira.mongodb.org/browse/GODRIVER-1883
Ref https://jira.mongodb.org/browse/GODRIVER-1833

Hi 策 高, thank you for the report!

That sounds like expected behavior. A fixed number of connections are created per server for monitoring. This is in addition to >the connections created for application use (which is dictated by MinPoolSize and MaxPoolSize).

For Go driver 1.4.0+ there are a fixed 2 monitoring connections per server.
For Go driver < 1.4.0 there is a fixed 1 monitoring connection per server.

When initializing the client with default configs, there is more than 1 connection (sometimes 2, sometimes 3) to the specific server.

If no MaxPoolSize was specified, the default MaxPoolSize is 100. And application connections are created as needed. The higher >rate of concurrent operations, the more application connections will be created, capping at MaxPoolSize.

When I set the MaxPoolSize to 2 and MinPoolSize to 2, I got 4 connections which are also unexpected.

If you are connecting to one server, since there are two monitoring connections, that is expected.

Sincerely,
Kevin

We do not want to initSeed in Sum64.

// Sum64 returns h's current 64-bit value, which depends on
// h's seed and the sequence of bytes added to h since the
// last call to Reset or SetSeed.
//
// All bits of the Sum64 result are close to uniformly and
// independently distributed, so it can be safely reduced
// by using bit masking, shifting, or modular arithmetic.
func (h *Hash) Sum64() uint64 {
	h.initSeed()
	return rthash(h.buf[:h.n], h.state.s)
}

Now we only have a mongo database, we need to introduce a TSDB to store metrics.