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
