Bolette Jurik (SB)
In this testbed experiment we focus on performance. The earlier experiment EVAL-LSDR6-1 on mp3 to wav migration and QA using xcorrSound also focused on correctness. Moving the workflow to Hadoop to prove scalability, should not affect correctness of the tool.
- Scalability The workflow must be able to process a large collection within reasonable time. That is we want to be able to migrate and QA a large collection of radio broadcast mp3-files (20 Tbytes - 175.000 files) within weeks rather than years. The goal of 1000 for NumberOfObjectsPerHour would mean that we can migrate the 20TB radio broadcast mp3 collection in a week.
- Reliability The workflow must run reliably without failing on a large number of files, and it must be possible to restart the workflow without loosing work.
- Correctness/Scalability We must believe to some extent that the automatic QA correctly identifies the "questionable" migrations, such that these can be checked in a manual QA process. We must however also insist that the number of migrations to check manually is minimal, as this is a very resource demanding process. The goal for QAFalseDifferentPercent has been changed to 2%. This means that we would have to check 3500 migrated 2 hour wav files manually. This is already too resource demanding. However the poor quality of the original files is a great challenge for the content comparison tool, and it turns out this is also too much to ask!
This table shows the results of the evaluation of the mp3 to wav migration and QA performed on the SB Hadoop Cluster.
|Metric||Description||Metric baseline||Metric goal||2014 April 8th*|| 2014 June 17th-23rd**
|NumberOfObjectsPerHour||Performance efficiency - Capacity / Time behaviour||18 (9th-13th November 2012)||1000|| 204
|QAFalseDifferentPercent||Functional suitability - Correctness||0.412 % (5th-9th November 2012)||2%||
*Based on the small experiment from April with max split size 128 below.
**Based on the large scale experiment from June below.
The conclusion is that the workflow does scale! We will not be able to migrate the collection in 1 week, but we will be able to do it in one month on the SB Hadoop cluster, which is considerably better than the one year needed without Hadoop (last evaluation). The conclusion on correctness is really more of a discussion... The measure QAFalseDifferentPercent is defined as
All run on a file list of 58 files (7.2Gb in total).
|| 37m, 58.593s = 2278.593s
|| 24m, 1.9s = 1441.9s
|| 18m, 17.917 = 1097.917
|| 17m, 3.176 = 1023.176
|| 16m, 54.703s = 1014.703s
|| 17m, 29.96s = 1049.96
The small experiments were mainly run to decide an optimal max-split-size (or an optimal number of map-reduce map tasks). The exact number of MR map tasks seem not to have a big influence on performance, as long as we have more than 12. That is as long as max split size is at most 256 on an input file list of 58 files. We note that we get approximately twice as many launched maps for the waveform-compare Hadoop job, simply because the input list is approximately twice as big, as it is a list of pairs. We can of course adjust this to get approximately the same number of jobs, but it does not seem to be important for the performance.
The large scale experiments were held up for a while, due to too few connection to storage. As this job writes very much data, the Isilon disk I/O and CPU use were being maxed out, even though we were trying to "play nice" and only run 24 maps concurrently. The number of connections to the 16 nodes Isilion storage solution at SB were 2 when the small scale experiments were run. It was then set up to five connections before we ran the large scale experiments.
This line of tests will focus on scalability. If max-split-size=256 (bytes) gives us 2*12 maps on an input-txt-file with 58 files, this means 256 bytes is approx 58/12=4,8333 files, so one file is approx 256/4.8333=52.9655 bytes. Then if we want approx 2*12 maps on an input-txt-file with 1000 files, we want max-split-size to be approx 1000/12*52.9655 = 4413.7931 bytes.
The jobs were run on file-lists of approximately 1000 files (100MB); the max.split.size was set to 4414; and each job writes approximately 3.1TB of intermediate and output wav files (+ some small log files).
|date||size:#mp3s||total size||duration||total duration||NumberOfObjectsPerHour||failure||total failure||QAFalseDifferentPercent|
|2014 Jun 17||1000||1000||4h, 33m||4h, 33m|| 220
|2014 Jun 18||1000||2000||4h, 23m||8h, 56m|| 224
|2014 Jun 19||999||2999||4h, 20m||13h, 29m|| 222
|2014 Jun 20||1000||3999||4h, 27m||17h, 56m|| 223
|2014 Jun 23||999||4998||4h, 28m||22h, 24m|| 223
ReliableAndStableAssessment Reliability - Runtime stability
For some evaluation points it makes most sense to a textual description/explanation
This evaluation covers performance, reliability and functional suitability to some extent_._ We did not look at the metrics MaxObjectSizeHandledInGbytes and MinObjectSizeHandledInMbytes. These measures would certainly contribute to the evaluation. Our collection ([Danish Radio broadcasts, mp3|../../../../../../../../../../display/SP/Danish+Radio+broadcasts%2C+mp3|||\||]) has mp3 files varying very little in size (approx. 2 hours, average file size 118Mb, largest file: 124Mb) and the workflow thus produces wav files varying very little in size (around 1.4Gb *2 per mp3 file). The test mp3 files used under development were of course considerably smaller (around 7Mb) and produced smaller output (around 50Mb*2 per mp3 file).
We did also not look at the metrics ThroughputGbytesPerMinute, ThroughputGbytesPerHour, or AverageRuntimePerItemInHours. These are all possible to compute fairly easily though.
WORK IN PROGRESS
The evaluation does not cover
- Organisational maturity
- Planning and monitoring efficiency
- Commercial readiness
Remember to include relevant information, links, versions about workflow, tools, APIs (e.g. Taverna, command line, Hadoop, links to MyExperiment, link to tools or SCAPE name, links to distinct versions of specific components/tools in the component registry)
We would like to store sufficient information about an experiment (hadoop program, configuration, etc.), so we are able to rerun it. For this purpose, ONB is providing a WebDAV - if you have questions and need more information, please contact Sven or Reinhard at ONB.
Taverna workflows will still be stored on myexperiment.org.
Please use the following structure for storing experiment results
Could be such things as identified issues, workarounds, data preparation, if not already included above