It's not clear to me why reads must be serialized at all. Maybe this could be re-thought? Maybe there should be a way to tell SQLite that a certain DB or table is to be read-only and unserialized?
On Sun, May 13, 2018 at 7:15 AM, Keith Medcalf <kmedc...@dessus.com> wrote: > > Say Hi to Gene! > > https://en.wikipedia.org/wiki/Amdahl%27s_law > > So I believe what you are saying is something like this: If I take a > child and have it count as fast as it can then it can count to X in an > hour. However, I take the same child but have it count as fast as it can > at five minute stretches, the sum of the X's is less than it was at one > go. If I get the child to do this at random intervals consuming juice > boxes in between, the sum of the X's is even lower, the higher the number > of interruptions becomes. > > In the second case the task consists of counting to ten and then drinking > a juice box. If you get one child, then it takes time X. Interestingly, > if you get two children, the tasks (empty juice boxes) stack up twice as > fast. There is some overlap between the operations. As you add more and > more children it goes faster and faster, but not quite. Eventally all the > children are drinking the juice box as the same time and adding more > children does not make things go faster. > > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > > >-----Original Message----- > >From: sqlite-users [mailto:sqlite-users- > >boun...@mailinglists.sqlite.org] On Behalf Of Techno Magos > >Sent: Sunday, 13 May, 2018 04:51 > >To: sqlite-users@mailinglists.sqlite.org > >Subject: [sqlite] Multi threaded readers on memory sqlite cannot > >scale > > > >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? > > > >2. Running the same example on sqlite *file *(multi threaded mode; > >WAL > >journal) scales almost linearly; so 6 threads provide nearly 6xN > >throughput. Single threaded throughput is a bit slower (around 15- > >20%) > >than single threaded in-memory access (expected). > > > >So, memory sqlite is not really usable with multiple threads > >(readers). > >While one might expect that multiple readers of *memory *content > >could > >scale even better than with file content. > > > >Can this restriction be lifted? > >Is there some special mode possible to achieve scaling up throughput > >with > >multiple threads for memory sqlite content? > > > > > >Thanks > >_______________________________________________ > >sqlite-users mailing list > >sqlite-users@mailinglists.sqlite.org > >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Dictionary.com's word of the year: *complicit* _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
