[Rails] Re: Database Concurrency Without a Web Server?

Isak Hansen
Thu, 13 Jul 2006 21:57:41 -0000

On 7/13/06, Jeremy Kemper <jeremy@bitsweat.net>
wrote:
> On Jul 13, 2006, at 10:15 AM, Isak Hansen wrote:
> > I''m not sure introducing concurrency will boost your insert
rate
> > all that much.
> >
> > I whipped up a small test to check, but even with
> > AR::Base.allow_concurrency set to true it seems my db access is still
> > serialized. 10 connections are opened all right, but 9 are idle
> > whenever i check db stats.
> >
> > Any thoughts? - Source at <http://pastebin.ca/87122>
>
> The postgres and oracle adapters on edge rails use nonblocking query
> methods when allow_concurrency is set. Could you rake
> rails:freeze:edge and try with postgres?

Was indeed my adapter not being up to the task. After switching from
postgres-pr to a native postgres adapter, the connections got a whole
lot busier.


Might as well post my results, now that I got the thing to run.

I wouldn''t take this benchmark too seriously, but unless there are any
blatant bugs in my code, it should give some indication on what to
expect.. (development mode shouldn''t cause too much overhead?)

Numbers below are time taken to insert 20k rows.


Creating and saving the rows sequentially, each in a separate transaction:
     ar_basic: 122.281

Creating and saving the rows sequentially, split across transactions
of 2k rows. (bit large, but couldn''t be arsed to split into groups of
100)
     ar_trans: 60.141

Using connection.execute(), transaction size of 2k rows
   noar_trans: 21.141

10 concurrent threads creating 2000 rows each. One transaction per insert.
ar_concurrent: 193.812


Conclusion: concurrency bad ;)


Isak