I wish it were like you said. However, in my understanding multiple connections to the same database are realized by file system locks. So switching from serialized to multi-threading mode doesn't make much difference because the main slow down are the file system locks.
Here are some results which are almost identical to the previous results (even though I passed "SQLITE_OPEN_NOMUTEX" to "sqlite3_open_v2()" in the multiple connection tests): ------------------------------------------------------------------ SELECT_COUNT: 1,000,000 THREAD_COUNT: 2 Testing with one connections (ReadWrite) and filled table... Elapsed: 53.3 s Testing with multiple connections (ReadWrite) and filled table... Elapsed: 66.6 s ------------------------------------------------------------------ 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 ------------------------------------------------------------------ SELECT_COUNT: 20,000 THREAD_COUNT: 100 Testing with one connections (ReadWrite) and filled table... Elapsed: 10.0 s Testing with multiple connections (ReadWrite) and filled table... Elapsed: 54.2 s - Sebastian On Fri, Sep 21, 2012 at 6:03 PM, Olaf Schmidt <s...@online.de> wrote: > Am 20.09.2012 17:40, schrieb Sebastian Krysmanski: > > > >> What's your threading mode? > >> http://www.sqlite.org/**threadsafe.html<http://www.sqlite.org/threadsafe.html> > > Serialized >> > > This could explain, why you get these performance-results, you > reported before (comparing multiple connections vs. a shared one): > > > > I tested with a database containing one table with 50,000 entries. > > I then ran "SELECT *" on this table from 100 concurrent threads > > where each thread randomly selected 20,000 table entries. > > > The results are: > > > * using a single connection for all threads: 11 seconds > > * using one connection per thread: 59,3 seconds > > For the multiple-connection-approach (each Cnn having its own cache) > you will probably see better results, when you work against an > sqlite-binary, which was compiled (or set to) multi-thread > (-DSQLITE_THREADSAFE=2). > > So one needs to take care that the engine operates in the properly > matching modes for the two approaches when used in threads: > > - shared Cache (single dbHdl over all threads) => serialized > (SQLITE_THREADSAFE=1) > > - separate Caches (a dedicated dbHdl per thread) => multi-thread > (SQLITE_THREADSAFE=2) > > The last one does well for me at least on the Win-OS' > (not tested on Linux here). > My DB-Sizes are not that huge, so I can effort the independent > DB-Connection-caches on each thread in my server-threadpool. > > Olaf > > > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
