Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 7 of 7
  1. #1
    Member
    Join Date
    Oct 2005
    Location
    Pangbourne, Berks, UK
    Posts
    64

    Performance issues - both good and bad (6.2)

    I have been running Slimserver on a 5-6 yr old Toshiba Portege laptop for a while now, and have had very acceptable performance given its spec (Pentium II 300 MHz, with 128Mb RAM, running Win 2000). My music is 400 albums, 5275 tracks, 220 artists, mainly FLACs with some MP3s, sitting on an external USB drive connected to a NSLU "slug". Im using a wireless squeezebox 2. Its a bit slow when I turn the SB on, but I think the disk may have gone to sleep. Apart from the occasional slow response to remote control input , it works well, sounds great, and the laptop is extremely quiet so its left on all the time. Im running 6.2b2 4694 on the Tosh.

    So far so good.

    Ive just taken delivery of a new desktop - a Dell 5150, 3Ghz with 2Gb Ram, running Win XP sp 2, so I thought Id see how it compared, expecting blistering performance. (Turning on the Dell, I was amazed at how quiet it was, its got the new BTX chassis design with a single fan, and its so quiet, almost silent, well recomended)
    I dowloaded the latest version of Slimserver, 6.2.1 5024 (last nights), waited till it had scanned the music, and then had a play on the web interface. Initial screens were much quicker as expected, but then disappointment. Browsing Artists was quick, selecting any of these, showed the allbum list very quickly, but after selecting the album, it takes a long time to display the track list - anything from 7 to 15 seconds!! Thats a long time on a 3Ghz PC

    Going back to the Toshiba, I try the same thing - initially much slower to display the list of artists, and their albums, but actually quicker to display the list of tracks, typically 4 to 8 seconds.

    I'm confused , an old laptop with a puny spec faster than a brand new machine with lots of RAM ???

    Any ideas? or recomendations to make the new machine run any faster?
    I accept its not a head to head comparison as I'm running differnet versions but even so ....
    I'll do some more investigations, but in the meantime all suggestions welcome

    Regards
    Nigel

  2. #2
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    18,932

    Performance issues - both good and bad (6.2)

    > Any ideas? or recomendations to make the new machine run any faster?
    > I accept its not a head to head comparison as I'm running differnet
    > versions but even so ....


    In very recent builds there's a performance parameter which let's
    slimserver use ram instead of the disk to do some caching. Could you play
    with these parameters?

    --

    Michael

    -----------------------------------------------------------
    Help translate SlimServer by using the
    StringEditor Plugin (http://www.herger.net/slim/)

  3. #3
    Member
    Join Date
    Oct 2005
    Location
    Pangbourne, Berks, UK
    Posts
    64
    Michael
    I also spotted some discussion (with you & Dan) on this parameter in the unix thread
    Quote Originally Posted by NigelC
    The parameter is currently set to 100,000, the database file is 6.4Mb with 400 albums, 5274 tracks, 220 artists. Slim.exe is running using 60 to 63Mb memory
    I have increased the parameter to 500,000 and the response has improved. Album tracks now take 3 to 7 secs to display, which is a bit faster than mu old laptop. Increasing it to 1,000,000 doesnt seem to make any difference to speed or RAM used.

    I would have still expected a much bigger performance improvement on the new PC

    Nigel

  4. #4
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    18,932

    Re: Performance issues - both good and bad (6.2)

    >> The parameter is currently set to 100,000, the database file is 6.4Mb
    >> with 400 albums, 5274 tracks, 220 artists. Slim.exe is running using 60
    >> to 63Mb memory

    >
    > I have increased the parameter to 500,000 and the response has
    > improved.


    Are you sure you're talking about 100'000s?!? I can't see any reason this
    could still improve performance. I guess that your database file won't be
    much larger than about 10MB. 100'000 pages represent a cache of 150MB (if
    I understood Dan's explanation). This might be 10-15x your database size.

    I've got a similarly sized collection (505 Alben mit 6554 Titel von 434
    Interpreten), the database file is <8MB. I can't see any improved
    performance whether I use 10'000 pages or 100'000.

    > Album tracks now take 3 to 7 secs to display, which is a bit
    > faster than mu old laptop. Increasing it to 1,000,000 doesnt seem to
    > make any difference to speed or RAM used.


    I hope it will only use the RAM it really needs. 1'000'000 pages would be
    1.5GB - not what you'd want to dedicate to slimserver, I guess.

    --

    Michael

    -----------------------------------------------------------
    Help translate SlimServer by using the
    StringEditor Plugin (http://www.herger.net/slim/)

  5. #5
    Member
    Join Date
    Oct 2005
    Location
    Pangbourne, Berks, UK
    Posts
    64

    Cause of slow track browsing

    I have done a bit more digging and I think I have found the cause of the slow track browsing (or some of it anyway)

    I turned on some debug (d_info as a very lucky first guess). Slimserver checks that each track in the album, (and playlist probably) exists and hasnt changed (size or timestamp). This is what takes the time - on my setup, going off to the NSLU and external disc, following the file path through 6 levels of folder to find the track, just to see if it has changed. Is this expected behaviour?.
    At first glance, I wouldn't have thought it was. I would prefer to tell Slimserver when I change/add some tracks, or rely on the overnight rescan. But maybe it really needs to do this.

    Can anyone shed any more light on this?

    Nigel

  6. #6
    Perl Commando Dan Sully's Avatar
    Join Date
    Apr 2005
    Location
    Daly City, CA
    Posts
    2,864

    Performance issues - both good and bad (6.2)

    * NigelC shaped the electrons to say...

    >At first glance, I wouldn't have thought it was. I would prefer to tell
    >Slimserver when I change/add some tracks, or rely on the overnight
    >rescan. But maybe it really needs to do this.
    >
    >Can anyone shed any more light on this?


    Yes - this was changed in the 6.2 release - so that if one updates/removes
    tracks or metadata from tracks, they will be updated in the web interface
    right away. I'll see what I can do about improving this situation, either via
    pref or caching - which is the way it was before, albiet hard to understand
    from a developer's point of view.

    -D
    --
    Off the record, on the QT, and very hush-hush.

  7. #7
    Member
    Join Date
    Oct 2005
    Location
    Pangbourne, Berks, UK
    Posts
    64
    Dan

    Latest 6.2.1 (v5107) has made a big difference - both my machines run considerably faster. Thanks

    Nigel

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •