Am 24.09.2012 11:26, schrieb Sebastian Krysmanski:
Ok, I tried that. It definitely improves performance when using a lot
threads (15+)...
So I take it, that your last posted result here was using a
shared cache (in case of the multiple connections):
------------------------------------------------------------------
SELECT_COUNT: 133,333
THREAD_COUNT: 15
Testing with one connection (ReadWrite) and filled table...
Elapsed: 12.3 s (162,647.6 stmt/sec)
Testing with multiple connections (ReadWrite) and filled table...
Elapsed: 12.7 s (157,324.1 stmt/sec)
Whilst the following result (from an earlier of your replies),
was not using a shared cache (instead using separate caches
per thread in case of the multiple connections):
> ------------------------------------------------------------------
> SELECT_COUNT: 133,333
> THREAD_COUNT: 15
> Testing with one connections (ReadWrite) and filled table...
> Elapsed: 9.5 s
> Testing with multiple connections (ReadWrite) and filled table...
> Elapsed: 51.2 s
Possible things which could explain that (because it differs from
my results considerably) are potentially:
1. the setting for: PRAGMA read_uncommitted
2. the implementation of the Busy-Handler
Ok, just looking what my settings were for case 1...
and 'PRAGMA read_uncommitted' was at Zero, so this case
can be dumped I think.
So I suspect the latter case ...
Which Busy-Handler do you use, the built-in one?
called up per: sqlite3_busy_timeout(sqlite3*, int ms)
Or your own implementation?
In my own BusyHandler (I'm dealing only with Windows here)
my first (few) "wait-fast" calls in the Busy-WaitLoop are always:
Sleep 0
which according to the MSDN:
>
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298(v=vs.85).aspx
"relinquishs the remainder of the threads timeslice", but
will try to return as soon as possible in this case.
So, if you implement your own Handler (for Windows),
calling Sleep 0 first (a few times) may worth a try,
so that you give the pausing thread the chance, to
take up its work much earlier, in case the cause for
the blocking was only a really short one (on some
other thread).
Also worth noting in this regard is, that the TimeSlice for
low values as e.g.
Sleep 1
doesn't (always) send the thread sleeping for "exactly" 1 msec -
the time until the thread resumes its work depends in this
case (for such low values) on the settings which were
(only potentially) performed earlier with timeSetEvent...
By default Windows has a "Tick-Interval" of about 12-15msec
(as the minimum-sleep-time for millisec-values > 0).
But this "Tick-Interval-granularity" is explained also in
the 'Remarks'-section of the MSDN-page for Sleep().
Olaf
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
