Just a bit of thought here: if opening was at fault then 5 queries started at the same time would finish in different times (first open executes, then while first query executes second open can be executed, then first query already executed while second is still in works etc). So blocking delays are coming from somewhere inside and they should be evenly spread over opening or execution of the query so that it could guarantee nearly simultaneous finish of all 5 queries. The only things that I can think now: - I/O: either file system or VFS inside SQLite is implemented so that every call to it acquires some global mutex. - if query is actually made over the same virtual table and virtual table implementation again acquires some global mutex for each call to its functions.
Luke, does any of these applies to your situation? Do you register any non-standard VFS in SQLite? Do you select from real table or virtual one? Could you also post timings with shared cache turned on and when the same query is executed from different processes? Pavel On Fri, Mar 5, 2010 at 3:25 PM, Olaf Schmidt <s...@online.de> wrote: > > "Pavel Ivanov" <paiva...@gmail.com> schrieb im > Newsbeitrag > news:f3d9d2131003051131k23c7b61cueda0bcc72e6aa...@mail.gmail.com... > > Oops, pressed send unintentionally... > >> > Long story short - I suspect the open-call, to be the "blocker" >> > in your "SharedCache-Mode=Off"-scenario. > >> If database file is pretty large, query reads a lot of data while >> executing and all data read fit into database cache configured >> then I think I/O will be the main difference between "with-shared- >> cache" and "without-shared-cache" scenarios. > > The rest of your reply was probably meant for Luke, > but the statement above is from my post, so ... > > From his timing-results Luke clearly reports blocking > behaviour with Shared-Cache=Off (although the blocking > should only be reasonable with Shared-Cache=On) ... > So, since everybody seems to agree about, that without > Shared-Cache the blocking on sqlite3_step() should > *not* happen - I suspect the open-calls (in each threaded > request) to be the culprit. > > So, I don't mean my post with regards to the additional > overhead from the open-call, doing its "real work" (schema- > info-parsing and stuff) - instead from the results Luke has posted, > I'd think, that there's an active mutex in the open-sequence- > actions of SQLite, which prevents the parallelism. > > Olaf > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
