Bangin' on a Rok Amarok, KDE, and all that good stuff

17Jul/0911

DB changes — call for benchmarkers!

I've done some work in trunk over the past week that may have a huge impact on many of you Amarokers. Read on, and if you can do some benchmarks for me, fantastic.

First, the schema/table changes.

  1. We've seen some issues where people have, for whatever reason, ended up with InnoDB tables instead of MyISAM tables. This is probably the result of their DB being created long ago before we were explicitly telling the mysqle startup to skip InnoDB. This mainly causes a problem because some columns cannot be as wide as we'd like them to be when using InnoDB. So, the first thing being done is that an ALTER TABLE is being forced on every table to explicitly convert to MyISAM. In addition, ENGINE parameters are now used during table creation to be more explicit in the future.
  2. Some of you might have seen complaints in the debug output about indexes not being able to be created due to a max key length, which by default in MySQL is 1000 (compile-time option). So, some columns have had their widths adjusted so that all indexes are now successfully created.

Now, the other changes:

As we added more features, scanning got slow. Like, really slow. You'd spend more time running SQL queries than actually scanning your files. So I've been aiming to change that.

Over the past week I've committed changes that remove, per track, anywhere from 1 to 6 SQL queries. The exact amount is highly dependent on your file set, but there is a minimum of one less SQL query per track. If you've done a lot of file moves and AFT kicks in, it'll be an even more massive speedup. I'm going to try to do some further tuning, but already results are looking positive.

Nikolaj has reported that his scan time went from 68 seconds to 18 seconds -- more than 3x faster. Mikko didn't notice a speedup, but he said that whereas scanning used to peg his CPU at 100%, it no longer does so. What I want to know is: how does this affect *you*?

If you want to help, do the following:

  1. Backup your DB. If you're using external MySQL do a mysqldump, if you're using internal MySQLe backup the mysqle folder in the Amarok data directory.
  2. Update to a revision from a week ago...say, 995000.
  3. Wipe your DB.
  4. Start Amarok -- it will do a full scan because of the empty DB. Time it as it does the scan.
  5. Repeat steps 3 & 4, so that you can see what the time is like after caching.
  6. Update to current trunk (at least 998470).
  7. Repeat step 3.
  8. Repeat steps 4 and 5.

Then leave a reply here with your values. If you watch your CPU during each of the scans, report that here too. Thanks!

Filed under: Amarok, KDE Leave a comment
Comments (11) Trackbacks (0)
  1. Here’s what I got:

    r995000:
    1st time: 137s //and it crashed at 100% :D
    2nd time: 76s

    r998526
    1st time: 122s
    2nd time: 33s

    Really big improvement, Thanks and congratulations Jeff!

  2. Ok, so I decided to try this better and I found out there’s indeed a speed increase, but I didn’t try step 5 with caching.

    In older revisions the total scan time was split in two parts:
    - Real scanning (disk activity, changing entries in collection_scan.log)
    - Something else, I guess like building the actual database or initializing, etc..

    rev 995000:
    - 1st part: 11 min 40 sec
    - 2nd part: 2 min
    TOTAL: 13 min 40 sec
    http://i25.tinypic.com/rqw4nc.png

    In trunk the second part is totally gone :D
    The first part *is* the whole scan:
    - 1st part: 11 min 36 sec
    TOTAL: 11 min 36 sec
    http://i28.tinypic.com/2qvr1ux.png

    And another improvement is cpu usage,
    you can clearly see how it was before and after the upgrade.

    Overall it’s a 15% speedup :D
    Thanks Jeff.

  3. Btw.: Is there a tool which I can use to browse the MySQLe databases? Or dumping to a formatted textfile? I couldn’t find anything useful, as most tools are only for real MySQL servers…

  4. Glad you got a nice speedup. Based on the other user above and Nikolaj’s experience, if you tested it with caching it’d have been even more massive :-)

    Thanks for the results!

  5. Thanks for doing this! Glad you got a nice speedup.

  6. Ah, that’s what I was looking for! Thanks! I added it to the overview list on http://amarok.kde.org/wiki/Development. Hope that’s ok.

  7. Err, wrong thread. That was about MySQL Embedded, of course…

  8. Is there ever going to be plans for having a full MySQL server in use with Amarok? Are there any huge technological problems as to why this can’t happen? Obviously don’t make it the default, but allowing it would certainly be nice!

  9. Better late than never…

    (I tested against 2.1.1, as recompiling amarok takes ages on this machine…)

    2.1.1:
    1st: 1min 50s
    2nd: it went weird when I treid that…

    SVN:
    1st: 1min 29s
    2nd: 0min 56s

    So not bad I’d say… This is with about 3400 tracks. And CPU was always at 100%.


Leave a comment


No trackbacks yet.