We have a modest media library: about 95,000 music files and 1,100 station media files. Our items table has 96,600 rows.
When using the mAirListDB application, there are several nodes in the browse tree that lock up the application’s user interface for 30-60 seconds when they’re clicked. This is disconcerting and I’m geting complaints from our producers.
I’ve scoured the forums and can’t find any report of similar behaviour. I figure that might be because no one find this behaviour to be a problem or that we’re the only users experiencing this behaviour. For now I’m assuming the latter.
I’m curious to know how many items are in the largest browse nodes of other installations.
How long does your mAirListDB take to list a node with 10,000 items?
How do you sub-divide your media collections to keep the items-per-node count to a size that doesn’t impede media management workflows?
Hopefully I’m not the only one who will find the answers to these questions to be interesting. Thanks in advance for sharing your thoughts.
@henk , how long does it take to load your mp3 map in the mAirListDB tree view?
@UliNobbe , is your database hosted on the playout station (or across a network)? Which DBM to you use (we’ve tested this with PostgreSQL 9.3 and 9.5 running on a dedicated DB server)?
It’s the mAirListDB in local mode = second HDD on the same PC as the playout system.
Well, the PC is an older system, but this should have no relevant influence.
When I use database search in the browser window of the playout system the first time (new keyword), it needs more time than the second attempt. It does not matter if mAirList is started again or not; the cache seems to work.
I’m running a PostgreSQL Database. Don’t have the actual Version number on hand, I use the one that comes stock with Debian 9. It runs in a Linux Container, while my mAirlist runs in a KVM Virtual Computer on Win8.1 on the same hardware machine. I don’t see any performance issue with it.
Even connecting through the mAirlist DB Server from my home-Studio, is reasonable fast on a 100Mbit DSL line. The DB Server proxies the connection to the PostgreSQL.
EDIT: Here is the performance data of the DB Container, doing nothing else then the Database. It’s in German but I think you get the idea.
My database tree loads immediately. I never actually saw that he was built. Searching took a long time before (was resolved at the time) that I myself learned to search through the tree myself.
Our DB server is hosted by Ubuntu 16.06 on top of VMware on top of 4 Xeons, 16GB RAM and an iSCSI SAN. The server has 2 x 1 Gbps NICs connected to our core switch. Its long-term load average is 0.7. The network seldom goes over 5% utilisation.
For queries against the items table from the playout system, pgAdmin manages 2760 items/second; psql is little slower at 2415 per second. mAirListDB manages 960 items per second.
@henk, my tree view loads instantly. It’s clicking on sub-folders that reveals the problem.
Can you guys time how long mAirListDB takes from when you click on the “everything” (alles?) folder to when you can select the first item in the tabular view with your mouse. Wall-clock time should be fine. Use that time and the number of items in your database to work out a crude item transfer rate as I did above. I’m particularly interested in your result Shorty since you’re running PostgreSQL across a network.
The transfer rate that @UliNobbe reported for his local database is about 425 items per second.
