Fucking Awesome! Now what the hell am I going to work on for GSoC? O yeah, AP is still full of cruft.
On Apr 20, 11:37 am, "Nick Sieger" <[EMAIL PROTECTED]> wrote: > I've started a refactoring working towards creating a proper > connection pool class/object for ActiveRecord. Progress can be found > in my connection_pool branch on github [1]. Some notes about the work: > > - One connection pool object created and cached per > AR::Base.establish_connection call. > > - Connection pool manages the individual connections. Currently it's > still a hash of connections per thread but it should be easy to move > to a proper fixed pool with connection acquire/release functionality. > > - At some point, in order to leverage fixed-size connection pools, > we'll need to find a way for application code to notify the pool that > it's done with the connection. A controller after_filter is one > possibility, I'm interested to hear other thoughts as well. > > - Connection API has not changed significantly, but I hope to at least > make the connection pool API more sane and deprecate and/or remove a > lot of the cruft like > active_connection/clear_active_connections!/clear_reloadable_connections!/v > erify_active_connections! > etc. Anyone who uses these or knows the original intent of these, > please let me hear more about it. Their purpose seems less clear in > light of the refactoring so far. > > - Synchronization monitors have been introduced around both connection > pool and connection access through a new active_support Module > extension I wrote that lets you easily apply synchronization at the > method level. > > - allow_concurrency now simply flips between a real and null monitor > for connection pool access. > > - The synchronization overhead is small, enough that I'm wondering > what people think about possibly making allow_concurrency default to > true (favoring safety over a small boost in speed of connection > acquisition). I ran the AR tests for mysql, postgresql and sqlite3 > with master and my branch: > > master > ====== > test_mysql: 43.058775 seconds. > test_sqlite3: 39.885374 seconds. > test_postgresql: 36.002755 seconds. > > nicksieger/connection_pool > ====== > test_mysql: 44.72238 seconds. > test_sqlite3: 40.68397 seconds. > test_postgresql: 37.23015 seconds. > > nicksieger/connection_pool w/ default allow_concurrency = true > ====== > test_mysql: 45.641348 seconds. > test_sqlite3: 43.405034 seconds. > test_postgresql: 37.850598 seconds. > > (This is of course not an exhaustive benchmark, but at least gives you an > idea.) > > This might seem like YAGNI for a lot of you, but I think it has the > dual benefit of cleaning up the connection_specification code, plus > supporting the endgame for my standpoint, which is making the > connection pool implementation pluggable so that I can use the Java > application server's connection pool when running with JRuby. > > Comments appreciated! > /Nick > > [1]:http://github.com/nicksieger/rails/commits/connection_pool --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
