Hi Luke, Thanks for your advise, we will take into consideration some of the ideas you suggest, some others we have already considered it. Did you make any experiments on Matterhorn involving what you told us? Do you have any data? We will very thankful if you can share.
The reason of having 32bit vcpu is that we only have support for 32bit in our virtualization software, so that's it. About the processes, I've taken the information from the logs themselves, purging all the useless data. And I have to make one emend, the worker has 2 virtual cpu. Changed on the wiki too. Hector 2010/12/14 Luke Olson <[email protected]> > Hello Hector, > > > > Nice work on the breakdown of the processes. Was that taken from the logs > or manually acquired? This kind of information would be great to have in the > administrator interface for each recording. Is there a specific reason for > using 32-bit virtual machines instead of 64-bit? Even if the machines have > only 1GB of memory they can still benefit from architecture and instruction > improvements in 64-bit. > > > > > http://www.scribd.com/doc/363677/Benchmarks-AMD64-in-32bit-mode-vs-64bit-mode-Ubuntu > > http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1 > > > > None of those are specific to what Matterhorn is doing, but in general > 64-bit operating systems and software are much faster on the same hardware > (assuming it supports 64-bit). It would definitely be worth investigating > the possibility of switching to 64-bit virtual machines. > > > > Depending on the workload and what other virtual machines are hosted on the > same hardware it could be beneficial to run more virtual processors than you > have physical processors. For example if there are four processors/cores in > the host and three virtual machines with one processors each, it would make > more effective use of the hardware to run all of the virtual machines with > two or four virtual processors. In times when the engage or administration > server is slow the extra cycles could be used when processing multiple > lectures simultaneously. > > > > Upgrading hardware is something you’ll need to consider down the road if > Matterhorn sees wider adoption on campus. The current hardware won’t be able > to keep up with more than 8-10 hours of captured lectures per day based on > the current performance. Even a $500 machine could give at least five or six > times the performance of the current worker with the right selection of > hardware. If upgrading hardware becomes an option in the future maybe we > (the users) can make suggestions for hardware? > > > > All the best > > > > Luke > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Hector Canto > *Sent:* Tuesday, December 14, 2010 10:50 AM > *To:* [email protected] > *Subject:* [Matterhorn-users] Digging on performance ingesting > > > > Hi everyone, > > Due to the characteristics of our deployment and the limits of our budget > we decided to make some experiments to test the efficiency and duration of > the whole process - capturing, ingestion and distribution. > > After installing two capturers on conference rooms successfully we start > looking into the performance of our servers. We are testing on real > scenarios that fits our expectations: one to four hours captures, > occasionally consecutive. That's why we need to know how long the ingestion > process will last, to prepare our infrastructure and avoid jamming our > servers. > > New text would involve almost consecutive captures. > > I wish to know if anyone else is doing similar researches and what results > are you getting. > > The times we've got are: > > *Record duration: 55 min* > *Ingest duration: 2h 16 min* > > *Original files > *Size: 3,2 GB > Audio: MP2 44.1 kHz Stereo > Camera: MPEG-2 Interlaced 25 fps 720x576 px 6715 Kbps > Screen: MPEG-2 Progressive 25 fps 1024x768 px 1192 Kbps > > *Distribution files* > Size: 4,6 GB (originals included) > Flash > • Camera:H.263 720x576 px 709 Kbps 25 fps Audio APDCM > • Screen: H.263 1024x768 px 871 Kbps 10 fps > MPEG4 : 200Kpbs 320x240 Audio AAC > AVI > • Camera: MPEG-4 Visual 245 Kbps 320x240 px 25 fps Audio MP1 > • Screen: MPEG-4 Visual 277 Kbps 320x240 px 25 fps Audio MP1 > > *System characteristics* (as on the MH wiki) > 3 machines 1.0.x (admin,engage,worker) 1 cpu 32 bit 1 GB RAM except for the > worker (2 Gb RAM) > > *Ingestion* (approximate values) > Total time 2h 16 min 08 s > Unzip >> 6 s > Inspection and enriching>> 18 min 42s > Muxing >> 17 min 53s > Encoding >> 1h 09 min 31s > Image extraction >>9 min 58s > Text Analysis >> 15 min 34s > Distribution >> 3 min 21 s > > Regards > Hector Canto > University of Vigo > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
