ginjaninja 533 Posted July 6, 2014 Share Posted July 6, 2014 (edited) Version 3.0.5289.18702 there seems to be a significant performance bottleneck with persons and artists views in the dashboard, and its not related to cpu or disk subsystem performance. perhaps the database is the constraint along with the query. (roku and android clients dont seem affected but then their views have more spurious entries) all my content is stored locally on 5400rpm hdds my.application /ibn is stored on SSD (across 2 partitions of same ssd) all my views are 500 large (500 for movies, albums, persons and artists) q6600, 4x3.2ghzcpu 6Gb ram win7sp1 if i click (in dashboard) (views configured 500 large) home - movies - movies....the 1st 500 movies are shown <1second home - movies - persons....it take 20seconds to show persons.. likewise albums <1s artist or album artists >20 seconds. It is 100% reproducible for me and make no difference how many times the query is run (ie same after all images are cached etc the cpu and hdds are not breaking a sweat when viewed in perfmon. 2014-07-06 11:45:56.0530 Debug - HttpServer: HTTP GET http://localhost:8096/mediabrowser/Artists/AlbumArtists?SortBy=SortName&SortOrder=Ascending&Recursive=true&Fields=DateCreated&StartIndex=0&ParentId=ad14e238b35e6a32a39d2ef9c1a779f3&Limit=500&userId=59543acb15f7ccd6012f4447c75b0cf2 2014-07-06 11:46:18.9273 Debug - HttpServer: HTTP Response 200 to [::1]:55920. Response time: 22874.3084 ms FWIW the time for artists query grows somewhat linearly as the the number of objects increases, but even with 20 objects it is slow 2014-07-06 12:11:55.0781 Debug - HttpServer: HTTP GET http://localhost:8096/mediabrowser/Artists?SortBy=SortName&SortOrder=Ascending&Recursive=true&Fields=DateCreated&StartIndex=0&ParentId=ad14e238b35e6a32a39d2ef9c1a779f3&Limit=20&userId=59543acb15f7ccd6012f4447c75b0cf2 2014-07-06 12:11:56.3852 Debug - HttpServer: HTTP Response 200 to [::1]:56748. Response time: 1307.0747 ms 400 albums <.2 sec 2014-07-06 12:15:55.5739 Debug - HttpServer: HTTP GET http://localhost:8096/mediabrowser/Users/59543acb15f7ccd6012f4447c75b0cf2/Items?SortBy=AlbumArtist%2CSortName&SortOrder=Ascending&IncludeItemTypes=MusicAlbum&Recursive=true&Fields=PrimaryImageAspectRatio&StartIndex=0&ParentId=ad14e238b35e6a32a39d2ef9c1a779f3&Limit=400 2014-07-06 12:15:55.7699 Debug - HttpServer: HTTP Response 200 to [::1]:56753. Response time: 196.0112 ms whole log https://dl.dropboxusercontent.com/u/84611964/server-63540244767.txt Edited July 6, 2014 by ginjaninja Link to comment Share on other sites More sharing options...
ebr 14862 Posted July 6, 2014 Share Posted July 6, 2014 A while back, we made a pretty big sacrifice in performance accessing people in order to get our memory footprint down. I'm not sure we've had time to go back and see if there is any fine-tuning that can be done to bring some of the performance back but people are a very large set of distributed data to try and retrieve against right now. Link to comment Share on other sites More sharing options...
ginjaninja 533 Posted July 7, 2014 Author Share Posted July 7, 2014 thanks for feedback ebr. is it odd (does it concur with your root cause analysis) that 500 episodes of 24,000 returns quickly...500 people of 23000 returns slowly. 500 songs of 60,000 returns quickly...500 album artists of 650 returns slowly. I also notice viewing 200 album artists under reports interface is significantly quicker (by a factor of 100) than 200 album artists under music. I also notice that the two interfaces/queries do not return the same data set...the reports query returns the 'old' dataset with non album artists, eg. soundtracks and other organisational folders which are not album artists. might this explain why roku and android clients are not slow at showing album artists, they use the old query. Link to comment Share on other sites More sharing options...
ebr 14862 Posted July 7, 2014 Share Posted July 7, 2014 Yes, that makes some sense because we hold the entire library structure in memory. So actual items like albums or movies are very quick to find. Attribute-based groupings like artists or actors require a bunch of other operations now. But, when time permits, I'm confident Luke can fine-tune it. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now