Background Processing Changes

I spent most of my time this week trying to make things go faster without upgrading the old server things are running on. One of the bigger slowdowns I noticed was BackgrounDRb which wasn’t only taking up a hefty chunk of memory when running, but was also querying the database non-stop looking for new jobs in the queue.

I ended up switching out BackgrounDRb with Workling/Starling. While I lost the persistent job queue (something I’ll look into handling internally) the performance gains I’ve noticed are pretty significant. This change has been committed and pushed to github and I was looking forward to saying you can check out how I did it here but it looks like the change was too significant for GitHub to track. You can always download a local copy of the code and see what I changed if you’re interested.

It boiled down to installing working, starling, and some dependencies (like daemons). Converting the actual background scripts was pretty straightforward. I had to change the top of the classes to reference Workling instead of BackgrounDRb and strip out references to the persistent job queue. In the controllers/models that call the conversion I adjusted my function usage slightly (removed the hash wrapper I had on my arguments) and presto, things were working.

On another note, this week the Concerto team launched the Concerto public site at http://www.concerto-signage.com/. Its a pretty great looking site! I also spent some time working on the new version of Shuttle Tracking at RPI, which will be released under an Open Source license this year. I’ve slowly been re-writing the user portion of the application in Ruby on Rails and trying to optimize the code as much as I can for maximum performance. The javascript has also been completely reworked so we can use the faster Google Maps V3 API when they add functionality for polylines, or something that will allow us to draw the shuttle routes.

BackgroundRB Slowdown

I finished transitioning the thumbnail generation to a background process, using the same approach I use for video conversion because it seems like a thumbnail is just a special conversion. You can check out the commit here if you’re interested.

Adding another BackgroundRB worker was easy to do, but I’m finding that its wreaking havoc on my server. The box I’m developing bonsai video on is a pretty lightweight box (it might be my lightest now that I think about it). I choose to do this to force me to make sure my code would work well on slower boxes. So far I haven’t had any major issues. FFMPEG seems to convert videos fairly quickly, and up until today everything seemed under control. Combined, the 3 BackgroundRB workers are using up somewhere between 25 – 40% of my system’s memory, as reported by top. I’m not sure why the processes are using so much when they are sitting their waiting for work, and I doubt the sql overhead of pooling for new jobs (I use the persistent job queue) is that overwhelming.

This has made regular site navigation terribly slow, but at least pages don’t time out like they previously did when generating thumbnails. I think I have 3 options to fix things:

1. Refactor and combine the workers, so both videos and thumbnails are handled by the same worker. I suspect this might be able to save me 10-15% on my memory usage, but its not as clean as I’d like it to be.
2. Replace BackgroundRB with something else that may be a bit faster or more efficient. It looks like people have experienced the same problems I’ve had, maybe just on a smaller scale since they have more powerful servers. I would rather avoid this approach, since it means more development time reworking things I’ve already done.
3. Buy more RAM or upgrade the server. This one is tough for me, as I’d like this to be able to run on a fairly low-end machine, but I’ve found that Ruby on Rails has higher system requirements than something like PHP would. Additionally, this costs money.

For now, I’m just going to turn off the background workers so I can do some interface work.

Progress Updates

I spent some time today polishing up the basic video create/view/update/delete pages so they are a little easier to use. Not being a great CSS designer, I opted to use the Blueprint CSS framework [released under the MIT Lisense] to make things easier… I’ve never been a fan of manually crafting stylesheets for very complicated pages, and knowing that someone else will deal with the various browser-compatability hacks is a big relief. In addition to Blueprint, I’m using the Silk icon set from FamFamFam. I think I’ve used this icon set in just about every project I’ve done that doesn’t someone who is a “designer”. I was pleasently surprised to see they have icons for film.

On the coding front of things, the simple management (CRUD) of videos and collections is complete. I need to do a bit more work for adding additional videos to a collection, which I hope to have done by Wedneday… then I’m onto thumbnailing and conversion.

To database or not to database

For the past week or so I’ve been thinking about the storage of video files, and how to implement a storage system that is fast, effecient, secure, and reliable. My big question here is to use a database or not to use a database. I’m likely using MySQL for everything else, but video files are a bit larger than you VARCHAR(255) or even larger than a photo gallery image I’d store in a database. I’m concerned that throwing video files, ranging from 100MB to 5GB in a database might start to slow things down… which I really don’t want to happen. On the other hand, I can’t afford to have video files laying around in violation of a database foreign constraint, which might happen if a user deletes a video and the file delete fails (maybe its in use).

I’ve done some work storing large datasets in MySQL, but no work storing >25MB in a single field. Of course there would have to be a seperate media table, to prevent a stray ‘SELECT * FROM videos’ fr0m crashing the whole thing. but that still doesn’t convince me it will be as fast as it needs to be.

Another nice plus on the filesystem side is the mod_flv and mod_h264 streaming plugins for Apache. I know you can write a version of the flv streaming module in PHP, but I don’t see it having the speed of an Apache plugin.

I think ideally I’d like to store videos in the database or using something besides the regular flat file approach. Using Ruby on Rails might make this a moot point from a programming perspective, attachment_fu easily handles both file and database datastores.

If you have any experience storing large files in a database, I’d love to hear about it.