Too high TTFB when I publish/update a post


#1

I have the following problem in all my Wordpress apps in the VPS. Both admin and frontend have quite acceptable speed. TTFB is more or less 100-200ms. However, when I publish or update a post in admin, the TTFB becomes more than 10sec. Some times even reach 20secs.

I got a similar behaviour in apps with Woocommerce during the checkout process. When a user places the order and he waits for the thank you page.

I tried to talk with the support, but they don’t see anything wrong in the server’s side. I am lost on how to “debug” this and find the actual problem.

Things to keep in mind:

  1. It happens in every app with Wordpress
  2. It happens only on publish/update a post or placing a Woo Order
  3. The rest of the website speed is acceptable
  4. PHP v.7.2

#2

Go too “Tools” and then “Site Health”. Ignore the trivial warning messages about inactive plugins or themes. But if it says there’s an error with the REST API then that’s the problem. it waits for something to happen for 10 seconds before it gives up and then completes your page load. It happened to me. I had to shut off plugins one at a time till I found the one that was making that happen. Then I found an alternative to that plugin and then it was fine.


#3

If you get this consistently from different geos then it is definitely server side. This is not Cloudways “fault.” Either you have run out of server resources or you have a plugin sucking server side resources.

You can try to play with cloudways built in monitoring but that will only tell you that your server is spiking resources and your only actionable response is to upgrade your container with the appropriate resource.

The correct approach is for you to buy New Relic and use it to identify exactly what is the cause of your spikes and then either:

  1. Work with plugin devs/support to fix the issue
  2. Add resources to your server by scaling vertically (or reduce the number of apps on a server)

This is not Cloudways problem to fix. With Cloudways, your responsible for managing what goes on your server and they give you the ability to overload your server with too many apps or put Woo on a server too small for decent performance. If you can’t handle this yourself, they have paid support or you should look elsewhere for hosting that will cost more and keep you from making bad decisions about sizing. Some will even forbid the use of many plugins that cause these kinds of issues.


#4

Unfortunately, that wasn’t the case. The REST API is on passed tests :frowning:


#5

That’s not the case. Why? Because I don’t have serious peaks in resources usage. Both RAM and CPU is in acceptable values. Even during peaks, I barely have more than 70% of usage. Also, if it was a resource issue or a plugin, I would have encountered that in different places in the website. I have an 8GB RAM server with low traffic apps.

I don’t accuse Cloudways. The support guy spent quite a lot of time trying to find an issue. He did what he could. However, I did also every debugging process I was aware and couldn’t find something either. That’s why I came here. Not to blame CW, but to ask you guys, if you have any idea what could be wrong.


#6

Damn it! I found the problem! I never thought about it since I had the same problem in EVERY Wordpress app I have in the server. The common part on those where one plugin. Breeze.

I just tried to publish a new post.

With Breeze: 22sec TTFB
Without Breeze: < 1sec TTFB


#7

Glad you solved the problem, pretty much by definition the cause of your problem is a bottleneck of resources. “Significant” peaks would actually be irrelevant, you need to look for small but serious peaks.

Normal monitoring should NEVER test for this situation. It would be too intrusive and actually cause performance issues where none would otherwise exist. You’d have to check for CPU, RAM, various disk metrics, various network metrics to be running at least every 5 seconds in the traditional format. This is where an instrumentation approach like New Relic makes more sense. It’s like turning on a debug mode for resource utilization. You can then turn it off.

By the way, if you upgraded the hardware sufficiently, you could also hide the problem. For all you know, it could be just one upgrade on the container size. Only way to know is to test.


#8

The issue is Varnish ON within the plugin. Turn that off and the problem goes away.

Personally, I use Breeze but turn off Varnish on the server and the Breeze setting = no more problems.