# GPU-Enabled Serverless Workflows for Efficient Multimedia Processing
## 5 Results and Discussion
### Workflow Execution  
With the aim of testing the platform, the use case defined in Section 4 was deployed on AWS. Both the FFmpeg and _audio2 str_ functions were configured with the _lambda-batch_ execution mode in order to support videos of variable duration, since they could exceed the maximum running time of AWS Lambda just as shown in Section 5.1. The instance type chosen for their compute environments was m3.medium (the default in the SCAR configuration) due to its reduced on-demand cost ($0.067 per hour) and the lack of need for GPU acceleration. The memory allocated for both functions was 1024 MB as a result of the analysis of the applications involved. Although it is true that the functions could execute with less RAM, this amount was decided due to the Lambda linear allocation of CPU proportional to the memory. The same amount of memory plus 1 vCPU was specified for the job definition in AWS Batch. Figure 7: Launch, boot OS and terminate time of instances on AWS Batch. The YOLOv3 video processing function, however, was defined with the _batch_ execution mode and the g3s.xlarge instance type, as indicated in Section 5.2. Since these instances have a single GPU, several of them will be needed to process different videos in parallel. Therefore, to test the scaling of multiple VMs without incurring excessive costs, a maximum of three instances was determined for the compute environment. The job definition specification associated to this function was adjusted to take up all the resources of a g3s.xlarge instance (4 vCPU and 30.5 GB), considering that only one job can be scheduled at a time. Notice that in the _batch_ execution mode, AWS Lambda is used as the entry point for events that are then delegated to AWS Batch. These intermediate functions are therefore also priced according to the assigned memory and running time. In this case, 128 MB of memory was selected to avoid unnecessary cost. The average running time obtained in these job-delegating functions was 1230 ms, which can be considered negligible in the total processing budget. The experiment carried out consisted in processing ten four-minute videos with a resolution of 1280 \(\times\) 720. These videos were uploaded to the S3 _start_ folder in order to trigger the execution of the workloads. At the starting point, a single video is uploaded and, after a minute, another one. Five minutes after the beginning, three videos are uploaded simultaneously and, to finish, another five videos are uploaded at minute ten of the test. A summary of the overall execution takes place in Figure 8. The FFmpeg (purple) and _audio2 str_ (green) functions have been completely processed on AWS Lambda, taking advantage of their high parallelism for file processing. Furthermore, the visualisation of the YOLOv3 function, which runs entirely on AWS Batch, has been divided into two categories: the time that jobs remain pending in the job queue is shown in blue and, when they are processed on an EC2 instance, in yellow. As shown in the figure, after the autoscaling, up to three jobs are processed in parallel. This parallelism can be easily increased by configuring the compute environment to host a larger number of instances, thus allowing the platform to be customised according to the needs of the application preventing the user from explicitly managing the underlying computing infrastructure. Table 1 shows the running costs of the workflow for processing the first video, differentiating between the costs generated by AWS Lambda and the EC2 instance launched by AWS Batch. Amazon CloudWatch and S3 costs have been omitted since their low usage for this case study is covered by the AWS Free Tier. Similarly, AWS Lambda offers 400,000 GB-seconds of compute time per month, which would not incur costs if the platform does not exceed that threshold. Furthermore, as mentioned in Section 5.2, the cost per processing on GPU-enabled instances on AWS Batch is lower than if CPUs were used, since the processing  
Figure 8: Time chart for the processing of ten videos using the workflow.