Here's the situation:

I have a PHP/MySQL web application that accepts user uploads (pdf files). From these pdf files' pages a preview image is made on the fly and presented to the web app's users. Some pdfs might be on the large side, most will be under 50 MB but some extreme cases could be as large as a few hundred MB. A little waiting for the preview image for large pdf files is acceptable but no more than a minute let's say. Everything is running on one server for now, but soon the app will hit the server's limit on both storage and processing power.

My idea to solve the problem:

To deal with this situation I had the idea of having one or more pdf processing servers as needed, and one or more file storage servers. These two types of servers are mounted to the server on which the actual app runs using NFS. The app could then use GearMan to delegate pdf processing tasks to these processing servers. The processing server can mount the storage server and read the file stored there, process it and write its output to that server. The servers I'm talking about will be amazon ec2 instances.

The web app returns a link to the resulting pdf preview image on the storage server that was used which can then be used on the front end to show the image to the user.

My question:

I have zero experience with apps that use multiple servers, is this idea viable or is there a better way to do it? Is an NFS setup fast and reliable enough for this situation?


You're definitely thinking on the right lines, but in my experience, shared-storage on virtual machines is rarely performant, so I doubt i'd actually go down the NFS route in this instance.

The biggest disadvantage would be the Single Point Of Failure surrounding NFS atop EBS, which might prove quite tricky to mitigate. In a non-virtual datacenter, I'd use a clustered NAS Appliance to handle failover NFS. On EC2 I'm not sure how I'd go about that.

If you're already using Amazon EC2 for worker jobs, then why not store the assets in a S3 bucket. The performance is good, and the bucket is available from anywhere in the world, using the HTTP aceess method.

All you'd need to do is upload to S3, have the worker grab the file, process it, and drop the resulting assets back onto S3.

You can even mount a S3 bucket locally. https://stackoverflow.com/questions/10801158/how-stable-is-s3fs-to-mount-amazon-s3-as-a-local-directory

In fact, you could go more onto the Amazon stack and use their simple messaging service instead of (or as well as) gearman.

  • Thanks for your response! I have been looking into the S3 and SQS services but this would tie my app to the amazon infrastructure in way that is tricky to cut loose should we want to migrate to a different hosting company or whatever, right? I don't suppose the amazon cloud service is going anywhere any time soon but to be dependent on them still seems like some sort of risk. But maybe by building in proper abstractions into my application the migration efforts can be minimized – Asciiom Dec 16 '12 at 12:56
  • It would tie you down to an openstack compatible cloud. You should probably write some abstractions in anyway, or use pre-written abstraction libraries. – Tom O'Connor Dec 16 '12 at 13:14
  • 2
    Here's a SQS/SNS clone that was in this week's devops weekly. github.com/Comcast/cmb – Tom O'Connor Dec 16 '12 at 13:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.