Slow performance in episode Engine
by John Barnes on Mar 16, 2012 at 6:33:33 pm
I have just purchased episode engine, and I am not getting the speeds I had expected from it. To give some background, I have a mac pro and an xserve on an xsan and I am trying to encode about 90 min of footage into h.264. I have been using compressor to do this, but I wanted more flexibility in the codec settings than what compressor allows for. In compressor, I was able to compress the video in about 12 min. In episode engine the encode it taking over 45 min to compress.
Here are the settings I am using:
• Split and stich - 4 encodes on the mac pro and 4 on the xserve. I have varied the number of splits, but it has no effect on performance.
The CPU on both machines is maxed out, but I am only getting about 60 MB/s off the xsan on the mac pro and about 25 MB/s on the xserve. In compressor, I am used to seeing 200MB/s on the mac pro and about 80-90MB/s on the xserve. I have changed the encode settings in episode and nothing improves the encode time, or the read rate from the disk. Changing the number of simultaneous encodes does not improve it, and only decrease performance when I lower the encodes below 4 on each machine.
Since we are looking to have these turned around very quickly for posting to the web, a 45 min encode time is not an option. any help that any one could provide would be greatly appreciated.
Re: Slow performance in episode Engine by Kevin Louden on Mar 21, 2012 at 2:59:29 pm
I am wondering if for some reason Episode is using its file sharing instead of reading the files directly off of the SAN? Could you look at network bandwidth in comparison to fibre bandwidth during a test encode? If network read/write is maxed out but fibre is not then this might be the case. How are you submitting the files for encoding? Depending on how the file is referenced by Episode it might be thinking that the file is not locally reachable by both nodes and thus using its built in file sharing. In this case one node will share the file over the network to the other. This file sharing system is there to make things work when they otherwise would not, for example getting content to and from places that are not shared via normal sharing systems. It is not the most optimal way at times, such as what you might be experiencing.
If it turns out the source is being shared via our I/O server (the built in file sharing system) we can then figure out why and get the nodes reading off of the SAN directly as they should be.