[mythtv] Scheduler needs table keys?

[f-myth-users at media.mit.edu]

    > Date: Sat, 27 Jan 2007 23:28:55 -0500
    > From: Chris Pinkham <cpinkham at bc2va.org>

    > * On Sun Jan 28, 2007 at 02:11:22PM +1000, Paul Andreassen wrote:
    > > I noticed Chris Pinkham mention it takes 19 seconds for a schedule run, mine 
    > > takes under a second.  Why is that?  Are some "Recording Schedules" more 
    > > complex with better guide information.  If so, are there extra keys we could 
    > > add to speed it up?

    > There are a few things that can make big differences:

    > MySQL version (mine is 3.32.54 I believe, I have tested but swiched to 5.x)

I'm running 4.0.24 (that's what comes with Ubuntu Breezy).  Myth 0.18.1.

I'm not sure exactly which tables to look in to generate the stats
below, but to give an idea of my setup, "record" has 248 rows,
"recorded" 173, "recordedmarkup" 1247020, "channel" 81, "oldprogram"
17141. "program" 40865.  I've got 12-13 days of listings data, all
from DataDirect, across maybe 80 channels (I haven't counted).  I -do-
have a few "any channel" recordings (probably less than a dozen) but I
have a lot of recording rules in general.

    > Number of recording schedules (84 for me)
    > Number of channels defined (87)
    > Number of days worth of data (12)
    > Types of scheduled recordings (any/any is worse than exact time/channel)
    >     My breakdown looks like this:
    >        1 Timeslot Record
    >       12 Channel Record
    >       66 All Record (any time any channel)
    >        1 Weekslot Record
    >        1 Find One
    >        1 Find Daily
    >        1 Find Weekly

    > Then there are other things that our out of Myth's control that also
    > affect the speed, such as the CPU speed, remote vs local database, etc..

DB is on MBE.  I moved the DB to an alternate host (I think I may have
sent mail about this) and it just happened to run -just- enough faster
(mabye 30%) that IOBOUNDs didn't happen in some stress-testing (but
might still happen in real use).  But that's not a long-term solution
'cause that host isn't available to be a DB 24x7.  (It may also be
that I was saved by a few seconds' worth of TCP buffers between the
two hosts, or something like that.  Also obviously marginal.)

I'm running with 16meg of ivtv mpeg buffering per card, which is the
maximum allowed by the driver and is, frankly, enormous, consuming
almost half a gig of RAM on my MBE alone (granted, it's got 5 cards
in it).  But if emptying the buffers didn't stall, I'll bet I could
use the default 4meg buffers and be just fine; there's just not that
much disk bandwidth or head motion in normal recording, even across
half a dozen SD streams.  (I use JFS because I brought up Myth before
slow-delete was designed for ext3fs.)

    > As a test, I just changed all my "All Record" entries to "Channel Record"
    > on my development system and my scheduler runtime went from 17 seconds
    > down to 12 seconds.  I then changed all the "Channel Record" items to
    > "Timeslot Record" and the runtime went down to 6 seconds.  I did multiple
    > runs of each of these to make sure it wasn't cached data that was causing
    > the speedup.  I deleted 30 of the now "Timeslot Record" entries to drop me
    > to a total of 54 scheduled recordings and the scheduler runtime went down
    > to 3 seconds.

    > So from this quick test, you can see how drastic the differences can be
    > in different people's scheduler runtimes based solely on their types of
    > scheduled recordings and the number of each.

Yes.  But we should still fix the underlying bug.  We shouldn't expect
people to have to do mental gymnastics and laborious performance testing
just to avoid glitches in their recordings.  (And some of my glitches
are quite long---several seconds, which is plenty to miss, say, the
setup or punchline to a joke.)