> Serialized test (SQLITE_THREADSAFE=1): > > The main thread opens the database, sets the cache and busy timeout to huge > values and passes the db descriptor to the threads. > > Multithreaded test (SQLITE_THREADSAFE=2): > The main thread creates the other threads and wait; each thread opens its own > database connection and sets the cache and timeout (using a shared cache > required some changes to handle the LOCKED return codes, but didn't give > better results). > > Is this the expected behavior or am I missing something?
Yes, you made completely different tests. In first case everybody used the same connection, thus all worked in the same transaction space. I.e. transaction was committed only when all threads finalized or reset their statements. In a stress test environment I bet that was a very rare occasion, most of the time some thread still had its statement unfinished. So in the serialized test SQLite had less locking/unlocking operations to do and thus it worked faster. Pavel On Thu, May 3, 2012 at 5:04 PM, Marco Era <[email protected]> wrote: > Hi there, > > I've been using sqlite for a few years now and it worked fine in my > experience. > > Now that I have some time, I'm stress testing it to see how much I can get > from it; what I want to check is its performance in a multithreading > environment. > > To my surprise, it seems that serialized access to the database (which is the > default in the source code for Windows) is ~20% faster than multithreading > (no matter how the shared cache option is set). > > > > My test program creates 4 threads that do some work on a single table of a > ~200MB WAL-based database. > > First two threads do only SELECTs; third thread does UPDATEs; fourth thread > does INSERTs; the SQL commands are not wrapped into explicit transactions. > > > Serialized test (SQLITE_THREADSAFE=1): > > The main thread opens the database, sets the cache and busy timeout to huge > values and passes the db descriptor to the threads. > > > Multithreaded test (SQLITE_THREADSAFE=2): > The main thread creates the other threads and wait; each thread opens its own > database connection and sets the cache and timeout (using a shared cache > required some changes to handle the LOCKED return codes, but didn't give > better results). > > > > Is this the expected behavior or am I missing something? > Thanks in advance. > > Marco > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
