Re: [scalability, performance, DoS] To or not to process images at runtime

Marcelo de Moraes Serpa wrote: > My next project will be a kind of online photo viewer. All of these > photos will need to have watermark applied to them. The problem is > that, depending on the picture, different watermarks need to be > applied. The easiest solution would be to process these picture at > runtime using GD, apply the watermark(s) and serve them. The other > approach, would be to pre-process them (maybe using GD) and create > different copies on the disk, the obvious advantage being that it > could be served directly via the webserver (apache), but, it would be > much harder to manage (need to fix a watermark error? Re-process and > re-create the images on the disk...) and would take much more disk > space. I would rather process them at runtime, per request, however, > this site will probably have lots of traffic. So, I've reached a > deadend. Could someone share his/her experiences and thoughts and help > me decide? :) I think it depends on the amount of traffic you expect - high - off-line low-to-medium - on-line, on-demand, but cached. Disk-space is cheap, especially if you don't need to be worried about backup etc. I'm not sure why you think applying watermarks in an off-line process would any less manageable than doing it on-line. > FYI, The application would be custom built from the ground up using > PHP 5 (Not sure if we will use a framework, if we happen to use, it > will be probably CakePHP). At first, there would be no clusters, > proxies or balancers, just a plain dedicated server with a good CPU, > about 4GB RAM and lots of disk space. Sounds like you are planning to do the processing off-line then. You could even do a mix - if you've got a lot of photos (millions and milloins), applying the watermarks could take a while in itself, so you could leave that running slowly in the background, but combine it with an on-line process that does on-demand watermarking (when the photo is displayed). /Per Jessen, Zürich