Ticket #1433 (Closed: fixed)

This is continuing a thread from e-mail, but the problem is this: Playlists are taking a long time to play. The issue was thought originally to be in how SMIL files are processed, but apparently this is not the case. Then it was thought that either DB access or XML-RPC was the culprit, but this is also not the case. From the e-mail thread where the > is from Tomas and the response is from Akos: ============================= > ad: finding out where the bottleneck is ... > > Because some problems with running scheduler, I've done performance > testing on storageServer XMLRPC interface only. that's good. the problem came out with the graphical user interface anyway, not with the scheduler... > I've done several testing cases: > 1) running PHP XMLRPC client in bash cycle - it repeatedly invokes PHP, > runs client and sends XMLRPC requests > (locstor.accessRawAudioData and locstor.releaseRawAudioData) was this done for playlists, or audio files? to simulate the use case in question, one playlist and several audio file opens should be tested. but you can also trace what XML-RPC calls are made by invoking the GUI, uploading some files and then trying to play it through live mode. BTW, Doug, wouldn't you want to open a bug report on the issue, describing the test case in question? it seems there's a comminication problem with the e-mail lists, as we have to replicate the same information over and over... > 2) running XMLRPC requests in cycle in one PHP script > (locstor.accessRawAudioData and locstor.releaseRawAudioData) > 3) reference case - only system.methodHelp XMLRPC request in cycle in > one PHP script > > Time have been averaged from 100runs cycle. > Typical results from 'time' command follows. > > case 1: average = 0.421s so this takes 0.4 secs for one opening of an audio file (or playlist?). for a playlist with 4 audio files inside, that would be .421 * 5 = 2.105 seconds? > user 0m17.532s > sys 0m2.242s > > case 2: average = 0.225s this means for the same test case: .225 * 5 = 1.125 seconds? > The first case was wrong approach - significant time was spent on > client side cycle. > In the second case there may be still some influence from client side, > but not significant IMO. yes, probably this is better. in your test cycle, are the files only opened, or actually copied over as well? AFAIK the GUI opens the file, then makes copies of each (Ferenc can clarify this) > There seems to be roughly one half of time spent in XMLRPC routines and > the second half in storageServers' scripts. > In my opinion the response speed is good for interpreted language with > R/W db access (on my comp). > > Would it help in delay problem? yes, a delay of over 1 second is a problem.. but this is what we have, it seems. what we should think about how to access all resources as soon as possible. maybe we could call the accessRawAudioData method for each file as soon as they 'appear' in the GUI. but this would result in a huge number of open files. with that be a performance issue?