![]() ![]() ![]() I noticed that and solved that by adjusting phpThumbOf settings via manager: Hi, thanks a lot for the tip about phpThumb Max Cache settings, I've adjusted those accordingly.Īs for generating different image thumbnails for each page - yes, you're right. That will cut phpThumbOf's cache cleaning attempts short. If you don't want to mess with anything new, at least go to System Settings, core > phpThumb and set phpThumb Max Cache* (3 settings) to 0. 5.3 is reaching end of life, and newer versions improve performance and memory usage considerably. That is a massive image.Īlso, your server would benefit from a newer version of PHP. I think you will notice the difference in speed.Īlthough resizing a 116 megapixel image is going to be slow no matter what. On most sites you can simply uninstall phpThumbOf, install pThumb and be done, with no changes to templates or chunks needed. Have you looked at pThumb? It's my effort to create a faster and more robust phpThumbOf. This exacerbates the cache cleaning problem, plus it means visitors have to download the same image-just with a different name-each page they visit. (And the comical irony is it never even deletes any files, just wastes time.)Īlso if you use the same image on multiple pages-for instance a banner image on each page in a given section-phpThumbOf will create a separate thumbnail for each page. Every time the snippet runs it tries to clean its cache. On sites with a few thousand cached thumbnails this can add several seconds to the generation time for each page, even if phpThumbOf doesn't need to create any new thumbnails. Yes, phpThumbOf has a few face-palm-worthy moments when it comes to performance.īecause of its dumb attempt at cache cleaning, the more images in your cache the slower phpThumbOf gets. Currently there is ImageMagick noted there without any specific version or without "knowing issues" related with it. Well knowing all the above I encourage you guys to update the MODX server requirements page ( ) accordingly. And just for me to sleep well I also modified phpThumbOf snippet so that it rejects input files other then *.jpg, *.jpeg, *.png or *.gif. We finally solved our issue by installing latest version of ImageMagick (currently release version 6.8.8). swf files to phpThumbOf were processed very frequently - all resulted in server crashes. But together with outdated ImageMagick installed on server and with the fact that unsuccessful attempts to send. I think normally sending non-image file to phpThumbOf should lead to just logging unsuccessful thumbnail creation attempt, that's all. there was old version of ImageMagick installed on server (version 6.6.0-4 Q16) - problems with ImageMagick crashing server by sending non-image file has been reported here:.there were some really big images (up to 14,500 x 8,000 pixels, copied from former web site resources) sent to phpThumbOf.I did some further invertigations and found out that: ![]() These things helped to get significantly better web site performance but in fact didn't stopped server crashes.įinally I got some better server debug info and realized that not the Apache and PHP but process convert was consuming server resources. programmed custom caching plugin (inspired by Patrick Nijkamp and his xFPC extra) and mounted RAM disk as its cache folder.installed CacheMaster extra by Bob Ray as discussed on MODX forum ( ) and modified it to suit our AJAX needs.disabled deleting phpThumbOf generated thumbnails when clearing site cache by disabling phpThumbOfCacheManager plugin.I had just very basic (almost none) server debug info as server was maintained by outsourcing company, so I did the following: It seemed like high-traffic gradually consumed whole server RAM and finally led to server crash. The site had been working perfect during development but we ran into serious problems after going officially live. Apache + Lighttpd (for serving static content like images, stylesheets, javascript).phpThumbOf extra for generating image thumbnails (configured via manager to use convert utility).MODX Revolution 2.2.11 (traditional) - we used MODX Revo 2.2.11 but as it seems like this issue relates to ImageMagick more then to MODX and so I think it might affect latest MODX releases as well.AJAX driven web site installed on dedicated host.But I wanted to share our experiences that might help someone eventually. I'm not posting a question here actually as our problem has already been resolved, fortunately. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |