[digsmahler]

Nice! This is definitely an important tool when creating a site traffic in images to be displayed across a variety different sized screens. Having worked on this type of project before I'll mention a few challenges you have not yet addressed.

At some scale point, your single DynamicServer server will have more resize requests than it has CPU cycles to serve. The straightforward solution will be to add more DynamicServer instances. This means that your source image directory will have to be accessible from both instances. It also duplicates your cache directory, meaning a single image size could get generated on both servers. You might solve that by having a shared image cache network directory. Another solution could be to use a hash mechanism to determine a particular backend server from the load balancing layer, so any particular image would always be generated on the same instance.

Something interesting happens when people upload an image to their newsfeed. If it's a public newsfeed, there can be a good many requests of the image within the next several seconds at upload. This means that you can get multiple cache miss requests at the same time coming into your DynamicImage server. Your PHP processes are vertically partitioned, so your server will be simultaneously generating the resize. For users with only a few friends, this is a small waste of CPU cycles, but for users with massive user bases (e.g. Britany Spears), a single upload could grind your DynamicImage server to a halt just because of simultaneous duplicated work. Varnish (and other load balancers) can solve this by collapsing multiple requests to the same resource into a single HTTP call (https://varnish-cache.org/docs/3.0/tutorial/handling_misbeha...).