Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 3 123 LastLast
Results 1 to 10 of 30
  1. #1
    Senior Member
    Join Date
    Jun 2006
    Location
    Colchester, UK
    Posts
    338

    Problems caused by long waits to build web pages - any performance tweaks?

    I started a thread in the 3rd Party Plugins forum, about use of the web front end taking so many resources that (AlienBBC) streaming music freezes ("AlienBBC - radio stations interrupted by web page access")

    After some suggestions I upgraded from 6.22 to the lastest 6.5 Beta, in the hope that the combination of MySQL and split-scanner might sort out my problems. This has certainly helped, and the freeezes are now less often.

    I still get such problems though, and I assume these are down to lack of communication between the server & client. After a suggestion on the other thread I set --perfwarn=0.5.

    I now get lots of log output, as just about anything web related seems to talke longer than half a second (even when nothing is happening).

    To give some an extreme examples, here are the sort of things logged when I slect "All Songs" on the web page:

    Code:
    2006-07-02 17:40:25.0129 Timer Late > 0.5 : 2.54691505432129
    2006-07-02 17:42:04.1963 Web Page Build > 0.5 : 204.450978040695
    2006-07-02 17:42:04.2009   Generating page for browsedb.html
    2006-07-02 17:42:04.2676 Select Task > 0.5 : 204.671139955521
    2006-07-02 17:42:04.2857   Slim::Web::HTTP::processHTTP
    2006-07-02 17:42:04.2884 IR Delay > 0.5 : 198.674467802048
    2006-07-02 17:42:05.1504 Web Page Build > 0.5 : 0.698230028152466
    2006-07-02 17:42:05.1545   Generating page for status_header.html
    2006-07-02 17:42:05.1607 Select Task > 0.5 : 0.866274118423462
    2006-07-02 17:42:05.1633   Slim::Web::HTTP::processHTTP
    2006-07-02 17:42:05.9030 Select Task > 0.5 : 0.580109119415283
    2006-07-02 17:42:05.9057   Slim::Web::HTTP::processHTTP
    2006-07-02 17:42:05.9081 IR Delay > 0.5 : 0.678067922592163
    2006-07-02 17:42:05.9293 IR Delay > 0.5 : 0.698479890823364
    2006-07-02 17:42:05.9415 IR Delay > 0.5 : 0.709849119186401
    2006-07-02 17:42:05.9535 IR Delay > 0.5 : 0.721158981323242
    2006-07-02 17:42:05.9682 IR Delay > 0.5 : 0.733943939208984
    2006-07-02 17:42:05.9820 IR Delay > 0.5 : 0.747066020965576
    2006-07-02 17:42:36.1573 Select Task > 0.5 : 0.735414981842041

    204 seems a lot of seconds to wait for a web page to come back. Also, during that time the squeezebox is completely unresponsive.
    During this time slimserver.pl averages around 92% CPU, with flac, mplayer, mysql fighting for the rest.


    It has been suggested to me that this might be best discussed in the Beta forum, so here I am.


    My set-up:

    I am running the very latest (at time of typing) SlimServer build - 6.5b1 - 8242.

    My OS is Linux Fedora FC5 with no X-Windows or unneccessary services. I run this on an Epia Via motherboard with a 1Ghz processor and 512MB RAM. No other software (other than directly related to SlimServer) runs on this machine.

    I have one client - a Squeezebox 3. I nornally run this wirelessly, but when I tried it wired I didn't see any obvious impreovement.

    My music library contains 535 albums with 6451 songs by 232 artists.



    I hoped that 512MB of RAM (with very little used by the OS) would allow for the database to do some really good caching (especially given the relatively small amount of music I have), thus giving quick web access. Is there anything I can do to force the database to use spare memory for cache? Any other suggestions gratefuly received...

    Cheers,

    Richard

  2. #2
    Senior Member Patrick Dixon's Avatar
    Join Date
    Apr 2005
    Location
    UK
    Posts
    1,805
    The only thing I can suggest is that you try using the Nokia770 skin as when I last tried it, it seemed faster to me.

    Other than that I suspect you just need a faster processor. I recently ditched my old PII 300MHz server for a 2GHz Althon 64 and the web interface is like lightening by comparision!

  3. #3
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410
    Richard,

    That doesn't show long "Response Time" which are the time between the server checking to see if the client needs more data. This is good - it should minimise the chance of audio streams stalling.

    However the 204 seconds for a page build seems extremely long. I hope we can engage Dan here to see if there is anything which can be done about this. During this time the player user interface will be unresponsive.

    Dan - any views? Is there any extra instrumentation I can add on the database calls now we have split scanner code introduced?

    Adrian

  4. #4
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410
    As a datapoint, my server takes ~8 seconds to display All Songs from a database of 9000 songs after restaring slimserver. [but I guess the database files may be in memory]

    Server is an AMD Gecode 1.4Mhz (linux 2.6 says 2777.08 BogoMIPS), 512M of ram.

    Are you using the version of MySQL shipped with the server [test above is doing so]

  5. #5
    Senior Member
    Join Date
    Jun 2006
    Location
    Colchester, UK
    Posts
    338
    Quote Originally Posted by Patrick Dixon
    The only thing I can suggest is that you try using the Nokia770 skin as when I last tried it, it seemed faster to me.
    OK - Thanks - I'll have to give that a go.



    Quote Originally Posted by Patrick Dixon
    Other than that I suspect you just need a faster processor. I recently ditched my old PII 300MHz server for a 2GHz Althon 64 and the web interface is like lightening by comparision!
    I'm sure a faster processor would help, but I can't help feeling that that just avoids the root cause of the problem. As I've just added to someone else's thread, I run twonkyvision on a Linksys NSLU2 with a 266Mhz processor and 32MB of RAM. It has a web interface for listing songs/albums/artists, and it responds (with exactly the same set of music files) in a fraction of the time of SlimServer.

    There must surely be a config problem with my set-up. If not, there must be some pretty major potential performance improvemnt possibilities in the cuurent code...

    I try to do my bit re. avoiding wasting energy, and as I want to run my music server 24/7, I was keen to find one with low power consumption. I'm running my 1Ghz Epia machine on a 65Watt power supply, so I don't feel too bad about leaving that running all the time. I'd feel somewhat worse about something soaking up many hundreds of watts of power all day.....

  6. #6
    Senior Member
    Join Date
    Jun 2006
    Location
    Colchester, UK
    Posts
    338
    Quote Originally Posted by Triode
    A
    Are you using the version of MySQL shipped with the server [test above is doing so]
    Yep, I elected not to install MySQL as part of Fedora, so I only have the one that comes with SlimServer.

    Oh, and I have a reported bogomips of 2001.17

    Richard
    Last edited by SadGamerGeek; 2006-07-02 at 16:21.

  7. #7
    Senior Member
    Join Date
    Apr 2005
    Posts
    8,410
    Quote Originally Posted by Triode
    As a datapoint, my server takes ~8 seconds to display All Songs from a database of 9000 songs after restaring slimserver. [but I guess the database files may be in memory]
    Just repeated this after a server power cycle and got the same results so there is no extra caching going on.

    This suggests there is something taking a long time on your server or due to your database. We need a better way of measuring what is going on.

    Dan - any views?

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

    Problems caused by long waits to build webpages - any performance tweaks?

    * Triode shaped the electrons to say...

    >Dan - any views?


    Running --d_sql will give you the queries with timestamps.

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

  9. #9
    Senior Member
    Join Date
    Jun 2006
    Location
    Colchester, UK
    Posts
    338
    Quote Originally Posted by Dan Sully
    Running --d_sql will give you the queries with timestamps.
    No sooner said than done!

    This is for listing "all songs" from the web page when my squeezbox is in standby. I turned on performance monitoring with a minimum time of 1 second plus the --d_sql param.

    As you can see the web page build took 157 seconds this time, and there's a few "timer late" lines of up to 25 seconds.

    I'm not familiar with these logs, but I couldn't help noticing what I assume is a track ID of 4403 showing up quite a bit. Could there be something dodgy about it? If so, how can I show what track that actually is?

    Thanks for everyone's help so far,

    Richard

  10. #10
    Senior Member
    Join Date
    Jun 2006
    Location
    Colchester, UK
    Posts
    338
    Oops - hadn't notice the file didn't upload due to its size. I've now chopped it down (hope I haven't lost anything important)

Posting Permissions

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