Open ss23 opened 10 years ago
The reason I went out of the way to do that is for the modular ability to add any sort of tracking or modification of images necessary.
For instance, with the current structure, you can make a hotlinking plugin which can change the image (add a watermark) or anything like that if it has a specific referral url or something. I can also send an image hit out to Google Analytics or something even when the image is being hotlinked on another site.
I don't think it's worth given up that potential entirely, but it could be useful to perhaps make it optional (or maybe just check to see if image-related plugins are enabled) and it could be served by web server. That may require some reworking of the image ID format.
Either way, I'm considering this low priority.
This is a major blocker for the use on a high traffic site that is currently undergoing an evaluation of CruelImage. It's just not practical for us to incur such a massive performance hit for "we might have features there one day".
In any case, I'll work on it in a fork and see if I can make something extensible that would solve this issue. Easiest thing would be just being able to hook "where" an image is "found" (e.g. 'Your image finished uploading! Find it at (customized URL or something)').
Well, it's currently being used in the Piwik plugin, so it's not just for future potential.
Do you know of any benchmarking or information on the comparison between webserver serving static content and php using imagejpeg() and such? That could better tell me whether or not it's worth giving up the features in the design.
Web servers already have the ability to serve up static content such as images. By explicitly rewriting images to a PHP script, we're going out of our way to decrease performance.
Suggested fix would be to change URL scheme to something that allows us to recognize whether we actually need to hit PHP. We know right away that an image ID of just like
/image.png
doesn't require hitting PHP. We can know that/thumb/image.png
might require hitting it, so we can use the webserver to try serving the static file if it exists, else fall back to the PHP. And we know that/upload
is always going to require hitting PHP.