<al...@ipac.caltech.edu> schrieb im Newsbeitrag news:634ea812687a6d75a1ddf17adce883fc.squir...@webmail.ipac.caltech.edu...
> >> My primary concern now is to prevent a dead-lock. > > That seems to make sense now (I assume you're working > > "near a deadlock" with your multipe-client-requests, not > > going to sleep properly before the next retry). > > Still makes no sense to me, how the absence of re-try code, > while very silly - yes;), can explain the vast difference in > performance I see between the "local-disk" scenario and > the over-NFS scenario? Such things can be tested - just start the same Job you performed earlier locally, now against NFS (with only one single writer-instance). And that shouldn't be all that much slower than against the local disk. If it already is (whilst using the DB over NFS exclusively), well - then something is probably wrong with your NFS (only Samba-Shares here - but in case of single Writer against the share, it does Ok - not as fast as against the local disk - but "fast enough" (just what one expects due to the involved sockets under the hood). Then, if you find nothing wrong with the single-writer-performance, increase the writers-count step-by-step, to take a look at the additional locking-overhead. Same thing in the other way round (which would be my first test)... do your concurrency-tests against the local disk - I mean, you already have many CPU-cores apparently on your Client-machine - let this machine act somewhat like an AppServer then (without a "socket-interface"), local processes/threads working concurrently against the local disk. And there you have the "pure effects" - easy to see then, if there's something wrong with your busy- handling - or not - and maybe check your threading-settings which you use in the sqlite-binary (we use '2' here, and no shared cache, each thread having its own connection-handle). Olaf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
