4 ms·
nice write up.. just today I asked for a service that would do this http://news.ycombinator.com/item?id=1514991 http://news.ycombinator.com/item?id=1514991 ( so
by minalecs 16y ago
nice write up.. just today I asked for a service that would do this http://news.ycombinator.com/item?id=1514991 http://news.ycombinator.com/item?id=1514991 ( sorry for thread hijack) but basically I didn't want to do image processing on the same instance as the app is running because of the constraints of cloud instances.
Based on your steps listed here 1.Handle request 2.Fetch original source image from S3 3.Resize/apply effects 4. Return result back to user. Why not just resize/apply at time of upload and store in S3... are you resizing and applying effects on every request for an image ?
- jrnkntl 16y agoFrom the article: "For performance, each of our image servers cache the source, and any resize, locally to disk. Since images are never updated (only created), and get a unique ID for each one, we don’t have to worry about cache invalidation, only expiration. We can then write a simple script to remove images from this disk cache with files of an access time greater than a certain threshold (say 30 days). That way, if we change from one size thumbnail to another, eventually the old thumbnail sizes will get purged."
- daryn 16y agoLike jrnkntl said, we cache all resized copies. The reason we resize and apply effects at request time instead of at upload time is that our design needs may change over time, and this way we don't need to go back and batch reprocess things.