Am 20.09.2012 17:40, schrieb Sebastian Krysmanski: >> What's your threading mode? >> 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
