Support » Plugin: Custom Content Type Manager » Custom field: image: select image takes tons of CPU

  • I recently upgraded to 3.5.1, and that appears to have been the change, though maybe there is some way some other plugin is wreaking havoc with the system?

    I have a custom field that had an image selector in it. When I click on the button to bring up the dialog to select the image, it now takes 100% of one of the CPUs almost a minute before the dialog appears. We do have a lot of images (99 pages worth). I originally blamed disk access time, but after looking into that the disk is pretty idle, and the CPU is very heavily used.

    My PHP processes used to have a 30 second timeout, and that wasn’t ever hit, but now I’ve had to up the limit to 60 seconds to get the thickbox_results() function to return with data.

    I’m not thrilled about having to up the limit, on general paranoid principles, and obviously waiting a minute to open (and then another minute if I click on a different page within that dialog) is pretty annoying for a user.

    Is there anything I can do to speed up that dialog? My images are organized in the date folders, so there aren’t many files in any directory. 4791 files total.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Contributor fireproofsocks


    It’s probably the issue of image resizing: I’ve had nothing but trouble relying on WP’s native functions there, but it’s hard to craft a work-around because some servers don’t have Imagemagik installed (which uses disk-space instead of CPU/RAM). So your image selection lightbox is probably pulling up 10+ full sized images for that modal window (no scandir is used for that since image paths are stored in the database). You may want to toy with the CCTM –> Global Settings –> Cache Thumbnail Images option and see if that has any effect on the issue.

    Plugin Contributor fireproofsocks


    Probably worth checking your PHP logs too: not sure if you’re hitting PHP warnings that’s slowing you down.

    There are some PHP warnings on one of the pages having to do with not being able to find one of the images (there are some remnants of an old test domain in the database somewhere) Interestingly enough, those PHP warnings only occur when caching is turned on. And the dialog is left blank with an error about getting a reference for picture ID #…

    With caching on, it doesn’t speed anything up noticeably.

    The images that show up in the final dialog are small, and have auto-generated hash-type characters after the image name – We’ve generated a number of different sized thumbnail/preview images before, so I think that part is working fine.

    And the page load time is before the dialog displays, loading the images doesn’t take any time at all, from the browser perspective.

    I tried turning on the cache, and clicking around, but got the same delays as before – the delay must be in getting data out of the database somehow.

    Plugin Contributor fireproofsocks


    Interestingly enough, those PHP warnings only occur when caching is turned on.

    That makes total sense: when caching is on, PHP is trying to read the image into memory in order to render a smaller version of it. The names are generated via an md5() hash of the image attributes (e.g. name, size, etc) in order to ensure that the name of the cache file is unique.

    If you’ve got broken URLs in your database, then that could cause long load times. If you think it’s a database issue, then turn on your MySQL slow query log and see what trickles in. I’ve done a fair amount of tuning/profiling on the GetPostsQuery class to ensure its searches are reasonably fast (it’s what’s behind the lightbox queries), but some types of queries can be intensive, especially on large data sets. In a nutshell: WP doesn’t scale well for certain situations. Depending on how your query is defined (e.g. if you’re looking for images matching a certain taxonomy), then it’s hard to have an efficient query given the WP database structure. Hard to say if that’s what you’re experiencing, but it’s worth looking into. If you’re on shared hosting, you’ll start to blow out fuses with queries on large data sets no matter which system you use, so if that is in fact what’s going on, then you need to be thinking more about more robust options for hosting.

    Finally got back to looking into this again (setting the PHP timeout to 120 seconds usually solves the problem, but not that pleasant of a solution)

    The long timeout is occurring in Form->generate(), specifically, the foreach(search_by) loop.

    I’ll continue working on it, but thought I would pass that on, in case that gives you any ideas.

    Interesting – the slow down is in the author() function, we have 33K users on the site. But, as far as I know, the choose upload image template doesn’t even need the author information? I’ll have to see where/why that search_by term is added.

    Hrm – search_by=true on line 165 of get_posts.php is the trouble.

    I wonder if the search_by term could be set by looking at the $search_form_tpl variable (ie. parsing the template to see what tags are used (I’m guessing that is what the author/etc is being loaded in for – that the template could print out the authors if it wanted to?)

    Or since the templates are semi-hardcoded in the post_selector/search_forms the search_by terms could be hard-coded in the code too? Certainly writing a parser that read through the template file that was going to be used, and then only query the database for those fields would be the best option, but I don’t know how hard that is.

    Your thoughts?

    Plugin Contributor fireproofsocks


    Ah — 33k users is not something I’ve tuned for. Joining on related tables gets progressively slower the larger those other tables are, so I’m not surprised this blew out your query times. Make a feature request so that joining on the users table is optional and I can look into it when I’m back from vacation.

    Plugin Contributor fireproofsocks


    It’s ain’t “work” unless a paycheck is involved 😉

    My customers seem to think I’m always on vacation…

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Custom field: image: select image takes tons of CPU’ is closed to new replies.