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
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
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
Nah, just lower the “request limit” and you’ll be good to be good to go Chris 🙂
Thanks, I’ll give that a go.
