PDA

View Full Version : Where are --perfmon and --perfwarn fully documented?



JJZolx
2007-02-07, 11:58
Or if they're not documented, a quick tutorial maybe?

I'm trying to figure out where the 3-5 second delay comes from before each page is loaded when I browse Albums. The rest of the web ui is pretty fast on my server, so this slowness is quite noticable. Seems to be unrelated to either the sort order or whether using gallery or list view, but the number of albums on the page is a factor. On most pages, due to the way the pages are broken between letters, I get 100-150 albums, even though the items per page is set at 50. A page with fewer album ('Z') loads fairly quickly. I'm guessing that there must be individual queries being done for each album on the page?

Triode
2007-02-07, 12:37
Whats the speed of the server? I get second or so and have been working on
improving some of this, but latest 6.5 is as good as it gets at present.

In terms of perfmon & perfwarn - these are simply command line options to
turn on what can also be turned on from the Network and Server Health web
page. For 6.5 you will need to do use the web page as the perfwarn options
are only in trunk [command line options make it easier for development]

So assuming 7.0:

--perfmon - turns on performance monitoring, this is what collects the data
displayed in the graphs shown on the Network and Server Health pages
--perfwarn - turns on warning messages if a reading exceeds a given value,
this equates to the high warning threshold on the web interface, it also
enables --perfmon, meaning that the --perfmon option is not really needed

--perfwarn=0.5 will enable high warnings for a set of critical timers at 0.5
seconds, i.e. it logs if any of these timers exceed 0.5 seconds.

--perfwarn ? will display the set of specific server monitors you can set a
warning for, these include the critical ones above, but also more relating
to web page build etc

for web build try:

--perfwarn pagebuild=0.5,template=0.5

(note no spaces as it needs to be a single arguement following --perfwarn).
This will print a warning for each pagebuild and template process which
exceeds 0.5 sec. All of these are timed and put on the web page graph, but
only if the time exceeds the specified warning threshold is a log entry
generated

--perfwarn pagebuild=0,template=0

This sets the high threshold to 0 and hence prints timings for every
pagebuild and template process

Now pagebuild happens in two phases, first there's processing in the server
and then the skin template(s) are processes. The result is the html which
is then passed to the server select loop to return to the client. pagebuild
times everything, templates time each individual template.

To really understand you need to look at the perl - in this case probably
something like Slim::Web::Pages::Browsedb.pm

[For 6.5 you can do most of the above, but will need to use the web
interface to set the high warning threshold rather than use command line
options]

Advanced tricks: In the pagebuilds which take a long time there often a call
to ::idlestreams which means that the select loop is called to check if any
clients need more streaming data. This keeps the "Response Time"
measurement down as audio is sent to the players in the middle of building
the page. If you set a low threshold for response as well you can see where
this occurs in the middle of building your page. If you (via the web
interface) enable backtraces for a given warning, you can find out exactly
where a given log message came from as the calling stack is also displayed.
[Note this slows down the server.]

----- Original Message -----
From: "JJZolx" <JJZolx.2lnf5z1170874801 (AT) no-mx (DOT) forums.slimdevices.com>
To: <developers (AT) lists (DOT) slimdevices.com>
Sent: Wednesday, February 07, 2007 6:58 PM
Subject: [Developers] Where are --perfmon and --perfwarn fully documented?


>
> Or if they're not documented, a quick tutorial maybe?
>
> I'm trying to figure out where the 3-5 second delay comes from before
> each page is loaded when I browse Albums. The rest of the web ui is
> pretty fast on my server, so this slowness is quite noticable. Seems
> to be unrelated to either the sort order or whether using gallery or
> list view, but the number of albums on the page is a factor. On most
> pages, due to the way the pages are broken between letters, I get
> 100-150 albums, even though the items per page is set at 50. A page
> with fewer album ('Z') loads fairly quickly. I'm guessing that there
> must be individual queries being done for each album on the page?
>
>
> --
> JJZolx
>
> Jim
> ------------------------------------------------------------------------
> JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10
> View this thread: http://forums.slimdevices.com/showthread.php?t=32527
>
>

JJZolx
2007-02-07, 18:27
Whats the speed of the server?

P4/3.0GHz, 2GB RAM. The library has about 1250 albums and 15,000 tracks.

I ran with --perfmon on my 6.5.1 server today and every page access under browse Albums registered page build times of >1 and <5 seconds, with a 4.64 second max. That seems in line with how it feels when browsing.

The DB accesses were all 0.005 seconds or less, with 92% under 0.002. But what is easily seen in the stats is that the sheer number of queries involved in a single page build appears to be _insanely_ high. Just refreshing an album page in one window, then refreshing the Server Stats page shows the total number of queries increasing by as much as 700-800 each time.

700 queries to generate a single web page!

Triode
2007-02-09, 16:11
> The DB accesses were all 0.005 seconds or less, with 92% under 0.002.
> But was easily seen in the stats is that the sheer number of queries
> involved in a single page build appears to be _insanely_ high. Just
> refreshing an album page in one window, then refreshing the Server
> Stats page shows the total number of queries increasing by as much as
> 700-800 each time.
>
> 700 queries to generate a single web page!

I agree. If you don't sort by artist and have showArtist disabled, I assume
it if far less?

I believe this is currently causes by the logic to get the right artist
which does lots of database accesses per album.

JJZolx
2007-03-29, 19:17
> The DB accesses were all 0.005 seconds or less, with 92% under 0.002.
> But was easily seen in the stats is that the sheer number of queries
> involved in a single page build appears to be _insanely_ high. Just
> refreshing an album page in one window, then refreshing the Server
> Stats page shows the total number of queries increasing by as much as
> 700-800 each time.
>
> 700 queries to generate a single web page!

I agree. If you don't sort by artist and have showArtist disabled, I assume
it if far less?

I believe this is currently causes by the logic to get the right artist
which does lots of database accesses per album.

Yes, if the show artists setting is disabled it's considerably faster.

Why not just store the artist display string in the album record? Once a scan is completed this display string should never change for a given album, so at worst it should be one query per album. If necessary, do an additional pass through the database after a scan to populate the column.