Speed of refresh after editing a post

One of my users says that it feels as though Discourse takes longer to refresh a post after it has been edited than it used to. I looked for settings related to this, but couldn’t find any. In my testing, posts update between 10 and 15 seconds after the edit is saved, which does seem to be rather slow. Why not update the post immediately after the user finished editing?

And just for giggles, I’ll see if this site updates differently from mine. Yes, it does—refreshes seem immediate here. So the question is, what could be different between the sites?

Yeah it should be pretty much immediate, except when your sidekiq queues are full or if your server is severely under dimensioned.

My starting point would be:

  • Check the load of your server.
  • Check the latency if your queues in Sidekiq -> Queues
3 Likes

If you recently updated after a couple months then you’re discourse is likely processing all of your images. @bartv’s advice will show you if that’s the problem. There is a setting “rebake old posts count” that defaults to 80; you should likely change it to 20.

1 Like

Thanks, guys. We’re running at Digital Ocean, and it doesn’t seem like there are any CPU or memory issues.

And similarly, the Sidekiq graphs don’t seem to show anything amiss:

Other thoughts? Thanks!

Are you on CloudFlare? Are you sure you disabled all their JS compression features?

2 Likes

We are on Cloudflare, and we did have JavaScript enabled in their Auto Minify feature. I’ve turned it off and purge the cache and we’ll see if it makes a difference (or if we need it for other stuff). Are there other places Cloudflare compresses JavaScript?

Yeah, make sure Rocket Loader is switched off too.

Don’t turn them off domain-wide, do this with a rule:

Minification, Rocket Loader, Mirage and Polish should all be disabled. ‘Disable Performance’ achieves this.

Brotli compression is also unnecessary and has previously caused issues, it can be disabled at domain-level in the ‘speed’ section of the dashboard.

The only area where Cloudflare can really assist Discourse is with asste caching, feel free to create a secondary rule which enables cache level ‘Standard’ on /uploads/* if you don’t employ some other form of CDN.

2 Likes

Turns out the real culprit was CloudFlare’s Brotli https compression. The Auto Minify JavaScript didn’t make a difference.

You need a page rule as follows:

None of the ‘Performance’ features are supported with Discourse, Javascript minification has also caused issues in the past.

CloudFlare is ok as a CDN, but it’s also going to add unavoidable latency between client and server.

1 Like

Yeah, unfortunately, we’re at our limit for free page rules, so it’s hard to justify paying monthly for something that I can just tweak around in a slightly less elegant way. If we ever start paying for CloudFlare, I’ll definitely add this rule.

Ok, well just be aware that the next time you ask for support it’s the first thing we’re going to need for you to do. We can’t support installs running unsupported configurations.

1 Like

You can make the orange cloud in the DNS entry for Discourse gray. That solves everything.

4 Likes

Doh! Of course—good idea, and I’ll give that a try now.

4 Likes