Ok - yet another test. This time, with WAL enabled. Results are much better:
------------------------------------------------------------------ SELECT_COUNT: 1,000,000 THREAD_COUNT: 2 Testing with one connection (ReadWrite) and filled table... Elapsed: 15.8 s (126,316.8 stmt/sec) Testing with multiple connections (ReadWrite) and filled table... Elapsed: 41.0 s (48,792.7 stmt/sec) ------------------------------------------------------------------ SELECT_COUNT: 133,333 THREAD_COUNT: 15 Testing with one connection (ReadWrite) and filled table... Elapsed: 11.3 s (177,669.7 stmt/sec) Testing with multiple connections (ReadWrite) and filled table... Elapsed: 11.1 s (180,816.2 stmt/sec) ------------------------------------------------------------------ SELECT_COUNT: 20,000 THREAD_COUNT: 100 Testing with one connection (ReadWrite) and filled table... Elapsed: 11.3 s (177,155.8 stmt/sec) Testing with multiple connections (ReadWrite) and filled table... Elapsed: 13.6 s (146,847.6 stmt/sec) - Sebastian On Mon, Sep 24, 2012 at 11:26 AM, Sebastian Krysmanski <maya.li...@gmail.com > wrote: > Ok, I tried that. It definitely improves performance when using a lot > threads (15+) but decreases the performance considerably when using only > two thread (from 60s down to 100s). > > ------------------------------------------------------------------ > SELECT_COUNT: 1,000,000 > THREAD_COUNT: 2 > Testing with one connection (ReadWrite) and filled table... > Elapsed: 58.9 s (33,938.7 stmt/sec) > Testing with multiple connections (ReadWrite) and filled table... > Elapsed: 102.7 s (19,482.7 stmt/sec) > > > ------------------------------------------------------------------ > 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) > > > ------------------------------------------------------------------ > SELECT_COUNT: 20,000 > THREAD_COUNT: 100 > Testing with one connection (ReadWrite) and filled table... > Elapsed: 11.8 s (169,204.7 stmt/sec) > Testing with multiple connections (ReadWrite) and filled table... > Elapsed: 15.0 s (133,612.1 stmt/sec) > > - Sebastian > > On Fri, Sep 21, 2012 at 7:45 PM, Keith Medcalf <kmedc...@dessus.com>wrote: > >> >> On Friday, 21 September, 2012, @10:53, Sebastian Krysmanski said: >> >> > 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. >> >> Can you try passing the SQLITE_OPEN_SHAREDCACHE and SQLITE_OPEN_NOMUTEX >> to the connection per thread and see how that behaves. You get the same >> advantage of reducing I/O and memory management by using a single >> page-cache, yet you now no longer have serialization (or mutexes to enforce >> serialization) in the library call path. If the serialization/mutex code >> is causing any significant performance effect, this should demonstrate it >> clearly. >> >> --- >> () ascii ribbon campaign against html e-mail >> /\ www.asciiribbon.org >> >> >> >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> 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
