Support » Plugin: Autoptimize criticalcss.com power-up » ao_ccss_queue_control extremely slow

  • Chris Lemmer

    (@jchrislemmer)


    Hey there,

    We use NewRelic to monitor our website. According to the slowest transactions, ao_ccss_queue_control is causing a major issue on our side.

    This function is inside a cron that seems to run every 10 minutes on our site. The cron seems to run for 165+ seconds every time.

    Any idea why this function would be so slow?

    Thanks
    Chris

    The page I need help with: [log in to see the link]

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Optimizing Matters

    (@optimizingmatters)

    Hey Chris;
    It’s meant to be slow; it is the component that processes the job queue and that communicates with criticalcss.com to create jobs there, to get the status of those remote jobs and to fetch the critical CSS once the remote job is done. The HTTP-communication adds time to the (local) job processing and to avoid an overload of the remote service there even is automatic pausing taking place every X requests.

    But; if you’re going up to that many seconds, you might want to go in the “advanced settings” and define a reasonable “request limit” there, that should help.

    Hope this clarifies,
    frank

    Chris Lemmer

    (@jchrislemmer)

    Hey there,

    The script definitely has some kind of issue.

    Every time it runs, our server seems to struggle to handle requests. We have a container with 4 workers, so resources isn’t an issue. But the critical CSS cron script really seems to cause issues every time it runs.

    Here you can see from New Relic what happens every time the script run.

    https://snipboard.io/9sjHde.jpg

    Thanks
    Chris

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    Well, the graph shows average PHP execution time, which indeed (for the AO CCSS part) is what we described and as such is not (or should not be) an issue. Have you changed the “request limit” already?

    I think what is happening here is that your plugin is running a cron task for 3+ minutes every 10 minutes.

    This causes a single PHP worker to be hogged for 3+ minutes, so it’s unable to serve more requests until your task has completed.

    It just feels as though that’s bad architecture?

    Thanks

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    Nah, just lower the “request limit” and you’ll be good to be good to go Chris 🙂

    Thanks, I’ll give that a go.

Viewing 6 replies - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.