开发者

PHP Dynamic Image Resizing (on the fly)

开发者 https://www.devze.com 2023-02-26 09:10 出处:网络
At the moment our website stores 2/3 fixed image sizes. These are produced at upload time and distributed via our CDN. However we need to implement a more flexible solution, we have mobile and tablet

At the moment our website stores 2/3 fixed image sizes. These are produced at upload time and distributed via our CDN. However we need to implement a more flexible solution, we have mobile and tablet ap开发者_C百科ps in development that require a multitude of different sizes. Our proposed solution is to create a PHP script that can accept an image identifier (id/type/url etc) and size contraints. The script can then create the image on the fly and cache it for the next time.

Is this a feasible solution?

Also at the moment the CDN shields our web server from considerable load. Is there anyway to incorporate the CDN into this process once the image has been generated once? The only way I can think of doing it, is having the script return a URL to the image resource, but then the client needs to make 2 HTTP requests. A redirect could be quicker, but isn't that still bad practice for speed?


This kind of system is supposedly more reads then writes.

In order for your system to run fast, you should always pre-process as much as possible in order to lower the performance impact of the bigger part (reads) even if it increases the performance impact of the smaller part (writes).

In that sense, you should determine the sizes you need and create these resized images at the time of the upload (i.e. right after the upload).

There aren't a zillion valid sizes, most smartphones/tablets fall in but a few possible resolutions in the end, there is no way the pre-processing is going to become worse than just-in-time slow-the-whole-user-experience-down stuff.

Again, don't be fooled, anything just-in-time is A_LOT_SLOWER, because you have the isincache checked, the create part and then only the return.

And EVERY_SINGLE_IMG_REQUEST will include the cache check, and some will be needlessly slowed down at the important time (read) instead of eating a few cpu cycles needlessly (i.E. producing images that will never be seen) at the unimportant time (upload).


We did something similar just recently. The user uploads a file. Any request to any of the versions of the file goes through a script that checks if the image has been generated and generates it or serves it otherwise. There is a bit of overhead there but so far I'm fine with it. Then the script queues the file to be sent to our CDN (S3 on our case) and once sent updates the local references so next time the page is rendered using the CDN's reference. The redirect is something you definitely want to avoid.


If your server has Imagik installed, as most do as standard. Imagik actually supports it on the fly, just got to build up a function to do so, sorry this isn't amazingly helpful but I have used it in the past.

0

精彩评论

暂无评论...
验证码 换一张
取 消