WordPress.org

Ready to get started?Download WordPress

Forums

Custom Content Type Manager
Custom field: image: select image takes tons of CPU (12 posts)

  1. jondaley
    Member
    Posted 1 year ago #

    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.

    http://wordpress.org/extend/plugins/custom-content-type-manager/

  2. fireproofsocks
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  3. fireproofsocks
    Member
    Plugin Author

    Posted 1 year ago #

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

  4. jondaley
    Member
    Posted 1 year ago #

    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.

  5. fireproofsocks
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  6. jondaley
    Member
    Posted 1 year ago #

    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.

  7. jondaley
    Member
    Posted 1 year ago #

    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.

  8. jondaley
    Member
    Posted 1 year ago #

    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?

  9. fireproofsocks
    Member
    Plugin Author

    Posted 1 year ago #

    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.

  10. jondaley
    Member
    Posted 12 months ago #

  11. fireproofsocks
    Member
    Plugin Author

    Posted 12 months ago #

    It's ain't "work" unless a paycheck is involved ;)

  12. jondaley
    Member
    Posted 12 months ago #

    My customers seem to think I'm always on vacation...

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic