Descriptiondatabase/sql: expose DB.MaxIdleConns and add DB.SetMaxIdleConns
The purpose of this patch is to allow for significant improvements in concurrent database access using the standard database/sql pool. As evidenced by work derived from the Boundary "Go vs. Java" blog post, the current concurent performance is limited for certain use cases (such as net/http serving data from bmizerany/pq)[1]. Additional changes from the original blog post, including benchmarking using more modern tools is also available on GitHub[2], some results are included[3].
Additional notes:
* The current code defaults to 2 "idle connections". In reality this equates to 2 "active connections" for various reasons. This default value is continued only such that users would not be subject to unexpected semantic changes.
* There is no maximum limit implemented. While not the subject of this problem or patch, this should be implemented.
* The immediate close behavior (something I am tempted to consider a bug) has not been altered. This point may become more of a philosophical discussion. In my experience, it's better to handle bursts with grace where possible. This would also relieve the scheduler.
* It may make sense to move the mutex in database/sql to a RW variant with a persistent store of Conn objects and a free / use list (with a slow garbage collector). This would also simplify the Close anti-race logic.
* The second comment on Open suggests that drivers will implement an Open that returns a *DB. This is no longer the case, and this comment should be removed.
* The default value should be documented somewhere.
[1] http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/
[2] https://github.com/raggi/go-and-java
[3] https://github.com/raggi/go-and-java/blob/master/README.md#example-results
Patch Set 1 #Patch Set 2 : diff -r 616adac0bb59 https://code.google.com/p/go/ #
Total comments: 6
MessagesTotal messages: 6
|