[Support request] Critical problems in server win Image Processing Queue

Home Forums Support Critical problems in server win Image Processing Queue

This topic contains 11 replies, has 4 voices, and was last updated by  Leon 1 year, 4 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
  • #492758

    Elio Martinez

    Hi Tom,

    Our server is crashing constantly because of constant petitions to the server about wp imaging queue and we don’t know what to do – – [08/Feb/2018:20:50:57 +0000] “POST /wp-admin/admin-ajax.php?action=wp_image_processing_queue&nonce=758cc6df1d HTTP/1.0” 200 442

    Can you provide me some help?

    GeneratePress 2.0.2
    GP Premium 1.5.6

    Tom Lead Developer

    Strange, the entire point of IPQ is to resize images when the server resources allow.

    It’s likely due to a server setting, although that error message isn’t specific enough for me to know what.

    You can turn off the image resizer by defining a constant:

    define( 'GP_IMAGE_RESIZER', true );


    Elio Martinez

    Hi Tom,

    Do you know which kind of setting do we have to adjust in the server to avoid these problems?

    We have to stop the image resizer because is making a call to the server every time we have a homepage petition.



    Tom Lead Developer

    Do you have any plugins that are altering cron events in WordPress?

    Do you have a staging server you can play around on at all?



    I’m experiencing these exact same results, getting hammered from gp-premium plugin to admin-ajax.php… had to narrow this down tonight with New Relic as it was killing my site. Thankfully frontend is basically served from cache so no problems were seen by visitors. In fact, didn’t notice this for quite a while. Seems to be with version 2 and the replacement of how images are queued?

    New Relic

    WP dashboard has seemed sluggish to me for a while and I didn’t give it much thought until I noticed my site was going way over threshold speeds on backend.

    After disabling using: define( 'GP_IMAGE_RESIZER', false ); everything went immediately back to normal.

    I finally narrowed it down though… I am thinking this is leftover stuff from when you moved to the new image queuing system in 2.0?

    I noticed a transient item queing itself up ever 1 minute along with a CRON job. CRON job is supposed to be there, but this transient item looked out of place.

    After looking in wp_options table, it turns out I had 704,373 rows with %wp_image_processing% Yikes!!

    You can run the following query to check your table:

    SELECT * FROMwp_optionsWHEREoption_nameLIKE '%wp_image_processing%'

    Transient plugin didn’t seem to clean them up properly for some reason. So I went and deleted them manually:

    DELETE FROMwp_optionsWHEREoption_nameLIKE '%wp_image_processing%'

    After that it resolved itself. Hopefully this fixes your problem as it did mine Elio… took my whole evening to track this down and finally resolve it 🙁 But I still love you Tom! 🙂

    This didn’t happen on my other GP sites… so it appears perhaps a few people’s upgrades perhaps went bad or something?

    Note: I re-enabled GP_IMAGE_RESIZER after clearing out the above and everything is good.


    Tom Lead Developer

    Uh oh – saw your tweet last night and thought “someone is in trouble”!.

    That must be a bug in the IPQ library we’re using. It’s meant to be better on servers. Ugh.

    We’re super close to releasing GPP 1.6 (this was introduced in 1.5), but I’ll try to work in a fix.

    Thanks for the heads up!


    Tom Lead Developer

    Just checked out a handful of sites using resized images – no crazy transient counts.

    I also checked the IPQ GH issue tracker for any reports, and nothing.

    I wonder if this was some sort of weird one-off server issue.

    Either way, I really like how WooCommerce is doing resized images now, so I’ll be switching to their method instead of IPQ ASAP.



    Great thanks Tom for the updates, I appreciate it. Yes, I’m tossing this up to corrupt transients. After clearing out all those rows I’m good to go again.


    Tom Lead Developer

    Good, keep an eye on it. If you see anything weird just give me a shout.



    Hi Brian,

    Thank you for the post. I used your code: DELETE FROMwp_optionsWHEREoption_nameLIKE '%wp_image_processing%' and deleted over 41000 rows.

    And Tom, you remember I posted about the image resizing (on blog archive page with the Blog moduel from GPP) won’t work for me before? I guess it has something to say about this.

    Thank you all


    Tom Lead Developer

    I’ll be replacing the image resizer in GPP 1.8. While this issue is rare, I don’t like that it happens at all. Sorry for the inconvenience!



    Thank you Tom. No problem at all.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.