Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author nosilver4u

    (@nosilver4u)

    That means one of two things:
    1. you are losing connection to your server
    2. the server took too long to process the image(s), and returned an error

    In the latter case, you can try several things:
    1. disable any unused resizes on the EWWW advanced page
    2. increase the max_execution_time in your php settings on the server
    3. if you’re using lossy compression, try the fast lossy option on the cloud tab

    Thread Starter mln83

    (@mln83)

    Thanks for the feedback.

    I have now gone through the server logs and indeed it seems that the server is taking too long to process the images. The EWW plugin is causing time-outs in the server log.

    I have also started to get 504 time-outs when accessing the site from the front-end while the EWWW Cloud plugin is working at the same time in the WP backend.

    Would increasing WP memory limit help? It is currently set to 128MB.

    Best regards,
    Michael

    Thread Starter mln83

    (@mln83)

    Btw what is the difference between the standard lossy option and the fast lossy option on the cloud tab?

    Best regards,
    Michael

    Thread Starter mln83

    (@mln83)

    Okay. I had SiteGround (my server host) investigate the issue a bit further. Here is their response:

    “In order to allow more time for the optimization to execute properly, I added the following code in your .htaccess file:

    Code:
    <IfModule mod_dtimeout.c>
    SetEnv DynamicTimeout 300
    </IfModule>

    This should increase the value to 300. However, it brought the optimization up to the 14th image (batch of 20 images) and the execution was halted once more. The application is constantly retrying the optimization steps which is resulting with the same error.

    In order to complete the optimization, I would recommend that you perform it on smaller batches as the only other way to do is if we increase the Apache Timeout which on shared platform cannot be done as it will have dire effect over all of the customers hosted on the same GoGeek server.

    The timeout can be increased only if you are not sharing the available resources with another customer and this is possible with Cloud Accounts and Dedicated Servers which you can upgrade to from your User Area -> Add Services -> Upgrade.

    Should you need further assistance, don’t hesitate to contact us.”

    Perhaps an idea for a future update of EWWW Cloud would be to automatically divide large batches into smaller ones? So 20 image batches gets sliced into e.g. 5 image batches. I think this would help solve this time-out issue.

    Best regards,
    Michael

    Plugin Author nosilver4u

    (@nosilver4u)

    The difference between lossy and fast lossy is about 20% compression on average, but the speed difference can be much more substantial. SiteGround servers are constantly problematic for this, and the problem is a bit more complicated than they realize.
    EWWWW is already only doing 1 image attachment per request, but the problem comes in when either the resizes are too many to process in 30 seconds (even if they bump your dynamic timeout to 300, their servers almost always timeout at 30 seconds). Or, some images by themselves will take 40-50 seconds to process with TinyJPG, not including the resizes. What you’re seeing with it trying the same image over and over again indicates that the latter scenario is probably the case, otherwise it would eventually finish all the resizes and move on to the next image. Switching to JPEGmini (using “fast lossy” has generally been the only course of action available for SiteGround customers.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Temporary failure’ is closed to new replies.