Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re^2: Threads and DBD::SQLite?

by BerntB (Deacon)
on Dec 15, 2013 at 16:15 UTC ( #1067241=note: print w/ replies, xml ) Need Help??


in reply to Re: Threads and DBD::SQLite?
in thread Threads and DBD::SQLite?

Ah, thank you! The exact string "cache=shared" gave some Google hits. This was fixed for DBD::SQLite this summer, it seems.

For a start, retrieving a given number of records from a single thread&connection is nearly 2 orders of magnitude quicker than retrieving those same records via a connection made via a single connection in a separate thread.

Two orders of magnitude slower using threads?! Sigh. Does it help to set "read uncommitted" on? (You do that in the connect string too?)

A few questions: What OS are you targeting? What does your data (schema) look like? What do your queries look like?

Honking big, multiprocessor Linux servers with Oracle and more memory than you can shake a stick at. :-) I'd like to replace an old C hack using a few GBytes of RAM for querying some subsets of a few tables really quick (quite a lot of work is required for some queries). The queries are data structures easily converted to SQL.


Comment on Re^2: Threads and DBD::SQLite?
Re^3: Threads and DBD::SQLite?
by BrowserUk (Pope) on Dec 15, 2013 at 16:53 UTC
    Does it help to set "read uncommitted" on? (You do that in the connect string too?)

    Not in my experiments on windows. (No, it is a pragma. See below.)

    I do not have any great faith that my tests on windows will be reflected on *nix; so here is my test harness:

    I'd love to see the results from a few runs done' on other OSs.

    You can get threads::Q (my own, efficient, self-limiting queue implementation) from here.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      UPDATE: numbers are partly wrong; see further discussion lower down in this thread

      I experimented a bit with this, on Centos 6.5. I had only a threaded perl 5.19.7 handy.

      Initially I got similar (disappointing) results, but then I found two problems with the test program:

      1. It turns out that after the "Create primary index"; block, a $dbh->commit is needed to get the index to be used/committed.

      2. A (much) higher rowcount $N gives more interesting results. From around N$ = 10_000 and upwards, the threaded version *is* (much) faster.

      For instance, for rowcount $N = 100_000:

      $ perl 1067204.pl Using minimum thread stack size of 16384 at /home/aardvark/perl-5.19/l +ib/5.19.7/x86_64-linux-thread-multi/threads.pm line 49. Took 6.262891 seconds (for Populate db with 100000 records) Took 0.121979 seconds (for Create primary index) Took 0.905479 seconds (for Retrieve the whole lot) 100000
      Took 0.099463 seconds (for Read all 100000 records using 4 threads)

      So, it was a good approach after all.

        erix, I can't thank you enough for do that.

        1. Ouch! I swear I had it in there at one point, but looking back to where this code originated, it was missing or in the wrong place back then.

          Position and frequency of commits is one of the many variables I've been playing with trying to get a handle on how they affect the overall performance. For example, if you uncomment the line:

          # $n % 10 or $dbh->commit

          The insertion takes 4 times as long.

        2. $N is a command line parameter.

          My typical test runs consist of the command: for /L %t in (1,1,4) do @1045292 -N=1e6 -T=%t -Q=100 which is probably self explanatory.

        From around N$ = 10_000 and upwards, the threaded version *is* (much) faster.

        Weird thing is, varying the number of threads (-T=n) makes no difference to the time required to process all the records:

        C:\test>1049236 -N=1e6 -T=1 -Qsize=1000 Took 86.039947 seconds (for Populate DB with 1e6 records) Took 2.232394 seconds (for Create primary index) Took 16.897088 seconds (for Retrieve the whole lot) 1000000 Took 0.268509 seconds (for Read all 1e6 records using 1 threads) C:\test>1049236 -N=1e6 -T=4 -Qsize=1000 Took 85.957917 seconds (for Populate DB with 1e6 records) Took 3.164024 seconds (for Create primary index) Took 16.881054 seconds (for Retrieve the whole lot) 1000000 Took 0.251258 seconds (for Read all 1e6 records using 4 threads)

        Leastwise, not when reading the records for the second time. Comment out the "Retrieve the whole lot" block and then things get muddy again:

        C:\test>1049236 -N=1e6 -T=1 -Qsize=1000 Took 86.307525 seconds (for Populate DB with 1e6 records) Took 2.363253 seconds (for Create primary index) 1000000 Took 0.978504 seconds (for Read all 1e6 records using 1 threads) C:\test>1049236 -N=1e6 -T=4 -Qsize=1000 Took 86.182529 seconds (for Populate DB with 1e6 records) Took 3.017540 seconds (for Create primary index) 1000000 Took 1.925757 seconds (for Read all 1e6 records using 4 threads)

        Once the single-threaded, first pass through the data is removed, it takes twice as long for 4 threads to read all the records as it does for 1 thread.

        But then, why does it take the single-threaded, read-all 16 seconds to do so; when it only takes 1 second to start an entirely new thread, make a completely new connection, and then read-all the records?

        Many questions and little consistency from which to derive answers at this point. If you can see any other obvious cock-ups I'd be grateful to hear of them.

        (Ps. Any feel for how Pg would compare in similar a application?)


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        blockquote

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1067241]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (7)
As of 2014-09-20 06:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (155 votes), past polls