>2018-05-13 12:50 GMT+02:00, Techno Magos : >> Hello
>> I do not have clear examples to post on this but would like to >> report findings around multi threaded read access (single process) in a >> large system that uses sqlite. >> This may be a known issue/restriction of memory sqlite behaviour, >> but wanted to check with the list first: >> 1. Running 2, 3, ... 6 multi threaded readers of a single *memory >> *sqlite database (via shared cache mode) on an 8 core cpu shows no >> throughput gain at all compared to single threaded throughput. >> In fact, it shows a throughput drop: i.e. if a single thread can >> do N simple queries/sec, 2 threads .. up to 6 threads do a little >> less (10% drop) in total. This suggests that access to memory >> sqlite can only be serialized? No one has asked the $10 million dollar question yet ... why are you doing this? It certainly does not sound like you have a highly constrained itty-bitty wee boxen for which the "shared cache" was designed (ie, you seem to have more that 4 cycles per second of CPU and 10 bytes of memory). So what was the configuration which you WERE PREVIOUSLY USING which was deficient and for which you are trying this optimization? Everyone knows that when you use "shared cache mode" you are trading off memory and CPU cycles against performance. Shared Cache Mode is designed so that if you are *really* so inclined you can run SQLite on your Tandy Pocket Computer too (https://en.wikipedia.org/wiki/Tandy_Pocket_Computer) --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
