On Wed, 2008-07-30 at 06:53 -0400, Tom Donovan wrote:
> Calling sqlite3_busy_timeout() in dbd_sqlite3_open might be better than using
> the
> do { ... apr_sleep() ... }
> loop in dbd_sqlite3_select_internal.
Yeah, true. I may just rework it with that instead. Thanks for the hint!
> Nevertheless, I also see that SQLite is quite slow for concurrent updates;
> despite being very fast
> for reads.
Also true, but with the current 100 ms sleep, it is not just slow - it
is dead slow. At one point I thought Apache hung or something during my
testing, but it was just sleeping for a long time in all of its threads.
Once I switched from the original behaviour to linear backoff, I could
get about 40 times as many pages out. Worth fixing.
--
Bojan