Speed of refresh after editing a post

adamengst · January 29, 2019, 5:51am

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?

bartv · January 28, 2019, 2:55pm

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

pfaffman · January 28, 2019, 3:16pm

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.

adamengst · January 28, 2019, 8:18pm

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!

bartv · January 28, 2019, 8:27pm

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

adamengst · January 28, 2019, 8:42pm

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?

bartv · January 28, 2019, 8:46pm

Yeah, make sure Rocket Loader is switched off too.

Stephen · April 2, 2019, 3:35pm

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.

adamengst · February 13, 2019, 6:52pm

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

Stephen · April 2, 2019, 3:31pm

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.

adamengst · February 13, 2019, 6:57pm

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.

Stephen · February 13, 2019, 6:58pm

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.

Falco · February 13, 2019, 7:44pm

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

adamengst · February 13, 2019, 11:25pm

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