> -----Original Message-----
> From: Matthew Bentham [mailto:mj...@artvps.com]
> Sent: maandag 6 september 2010 15:07
> To: Justin Erenkrantz
> Cc: Bert Huijben; Greg Stein; Johan Corveleyn; Subversion Development
> Subject: Re: Worried about single-db performance
>
> On 04/09/2010 17:33, Justin Erenkrantz wrote:
> > Aha. Adding exclusive locking into our pragma
> > [http://www.sqlite.org/pragma.html] calls in "svn_sqlite__open":
> >
> > "PRAGMA locking_mode=exclusive;"
> >
> > brings the time for "svn st" down from 0.680 to 0.310 seconds. And,
> > yes, the I/O percentages drop dramatically:
> >
> > ~/Applications/svn-trunk/bin/svn st 0.37s user 0.31s system 99% cpu
> 0.684 total
> > ~/Applications/svn-trunk/bin/svn st 0.26s user 0.05s system 98% cpu
> 0.308 total
> >
> > I *think* we'd be okay with having Sqlite holding its read/write
> locks
> > for the duration of our database connection rather than constantly
> > giving it up and refetching it between every read and write
> operation.
> > As I read the sqlite docs, we should still be able to have shared
> > readers in this model - but, it'd create the case where there were
> > idle shared readers (due to network I/O?) would block an attempted
> > writer. With a normal locking mode, a writer could intercept a
> reader
> > if it were idle and not active. However, I'd think our other locks
> > would interfere with this anyway...so I think it'd be safe.
> >
> > Thoughts? -- justin
>
> I think it's essential to use exclusive locking for performance
> reasons,
> without it we will get just as many individual file ops as in 1.6 (and
> it's the number of file ops which causes the performance problem on
> windows).
Did you actually try a shared lock before suggesting this?
Getting a shared lock actually gives me better performance on this read only
operation then an exclusive lock and it doesn't block out other clients
(which would be a breaking change from 1.6)
Getting an exclusive lock on every operation would completely disable
Subversions most popular client: TortoiseSVN.
That is not something we can decide in just a few mails.
Bert
