Hi guys,
I've proceeded to test out whether SQLite could serve my needs and so far I
am pretty optimistic that I can continue to use it at least until my game
becomes massively popular. Wanted to share my results.
My game does not in fact require a lot of write concurrency. It is just the
daily processing of results that needs to happen concurrently. So I wanted
to see if using 2 DB's would work.
I have 2 threads and 2 DB's.
Threads:
* main thread
* daily processing thread ("DP")
Databases:
* main DB
* results DB
Usage:
* Main DB is read and written to by the main thread and read by the DP
thread
* Results DB is read and written to by the DP thread and read by the main
thread
So there is no write concurrency to any DB. The daily processing happens
once a day and takes about 10-15 minutes for 1M records in the main DB (very
intensive computations, particularly for tallying votes). In effect, the
results DB is the output of the DP acting on the main DB.
This seems to be working really well. I am testing a simulated load of
150000 clients, and the server doing all the DB work is running at my target
framerate of 30 fps. Typically with games we expect around 10% of users to
be online at peak, so let's say this solution supports 1.5M active players
or more. Good enough to go live with!
A few more details:
* Each thread has its own connection, opening the main DB and attaching the
results DB.
* I'm using WAL on both connections
* No operations return BUSY or LOCKED, and I don't use any mutexes.
Anyway I wanted to share these results and see if you had any comments.
Cheers
Tom
--
View this message in context:
http://sqlite.1065341.n5.nabble.com/Does-SQLite-lock-the-entire-DB-for-writes-or-lock-by-table-tp76921p77358.html
Sent from the SQLite mailing list archive at Nabble.com.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
