When a site requires login, do not show "site is overloaded" banner, there is no anon access

[meriksson (Martin Eriksson)]

Now and then we get this notification at the top of our forum:

Due to extreme load, this is temporarily being shown to everyone as a logged out user would see it.

I have a few observations and questions about this:

First, the server does not seem to be under extreme load. The last time I saw the warning our server monitoring showed that CPU load peaked at 24%, memory usage was just above 50% etc. As far as I know, no noticeable decrease in performance for users. So I wonder: What is the threshold for this warning and is it reasonably calibrated?

Secondly, and more importantly for me, the forum I run is completely private. Logged out users can not see anything except the login page. So the notification is incorrect, i.e. the page is not shown as a logged out user would see it, because such a user would not be able to see it at all. This has created confusion a few times because it has been taken to imply that the posts of our private forum are suddenly available to unauthorized users. I was myself quite alarmed the first time I saw it and from time to time I get questions about it from users.

Perhaps this warning should be rewritten? Or changed/disabled for private forums?

Is it possible to disable it for a particular forum?

[neounix (Dark Matter)]

@meriksson

So I wonder: What is the threshold for this warning and is it reasonably calibrated?

Hi @meriksson

FYI. This notice is triggered via a cookie:

if ($.cookie("dosp") === "1") {
        $.removeCookie("dosp", { path: "/" });
        notices.push(
          Notice.create({
            text: I18n.t("forced_anonymous"),
            id: "forced-anonymous"
          })
        );
      }

Reference:

https://github.com/discourse/discourse/blob/ba00cc8ec457ce708cc1aec5d25afc38495cc52a/app/assets/javascripts/discourse/app/components/global-notice.js

Searching for this cookie on github yields:

https://github.com/discourse/discourse/search?q=dosp&unscoped_q=dosp

Where force_anon is found here:

 def initialize(app, settings = {})
      @app = app
    end

    def call(env)
      helper = Helper.new(env)
      force_anon = false
      if helper.should_force_anonymous?
        force_anon = env["DISCOURSE_FORCE_ANON"] = true
        helper.force_anonymous!
      end

Reference:

https://github.com/discourse/discourse/search?q=force_anon&unscoped_q=force_anon

See also:

https://github.com/discourse/discourse/blob/19814c5e8109dfb30b8a96e0762d062b200db392/lib/middleware/anonymous_cache.rb

 MIN_TIME_TO_CHECK = 0.05
 ADP = "action_dispatch.request.parameters"

 def should_force_anonymous?
        if (queue_time = @env['REQUEST_QUEUE_SECONDS']) && get?
          if queue_time > GlobalSetting.force_anonymous_min_queue_seconds
            return check_logged_in_rate_limit!
          elsif queue_time >= MIN_TIME_TO_CHECK
            if !logged_in_anon_limiter.can_perform?
              return check_logged_in_rate_limit!
            end
          end
        end

   false
end

[codinghorror (Jeff Atwood)]

@meriksson

the forum I run is completely private. Logged out users can not see anything except the login page. So the notification is incorrect, i.e. the page is not shown as a logged out user would see it, because such a user would not be able to see it at all

That is a good point @sam on a completely private site the copy will be confusing … and maybe isn’t correct.

[sam (Sam Saffron)]

@meriksson

First, the server does not seem to be under extreme load. The last time I saw the warning our server monitoring showed that CPU load peaked at 24%, memory usage was just above 50% etc. As far as I know, no noticeable decrease in performance for users. So I wonder: What is the threshold for this warning and is it reasonably calibrated?

This warning shows up if NGINX ships a request to unicorn (the app server) and we notice a big delay.

Eg: (exaggerated)

• NGINX says … hey here is a request I got from a user at 1pm
• 1 hour passes
• App server get the request … yikes it too 1 hour for me to get it… I got to be overloaded.

You can control the threshold with these two settings:

https://github.com/discourse/discourse/blob/38a30a6e961dc28d473709d47c5a357eab64998d/config/discourse_defaults.conf#L227-L230

DISCOURSE_FORCE_ANONYMOUS_MIN_QUEUE_SECONDS and DISCOURSE_FORCE_ANONYMOUS_MIN_PER_10_SECONDS

Most importantly if your server has lots of extra capacity, add more unicorns by increasing UNICORN_WORKERS

If a site requires login, then I guess we should change the warning to something more severe (blue screen, you are rate limited).

This is the first time I heard of a site requiring login hitting this rate limit. Agree we should do a bit better here.

[sam (Sam Saffron)]

I am going to wait here for 1 more independent complaint.

Best we can do under extreme load, for “requires login” sites, is simply to render a blue screen saying “site is overloaded, try again later”. Would like to wait a bit before adding this and see 1 more complaint.

[anon82467725]

@sam

I am going to wait here for 1 more independent complaint.

It is happening on a very small private Discourse community I visit often. Gave me a 502 bad gateway nginx error, then it wouldn’t load at all. Eventually, it loaded, but it showed me the aforementioned banner message.

[codinghorror (Jeff Atwood)]

@sam

Best we can do under extreme load, for “requires login” sites, is simply to render a blue screen saying “site is overloaded, try again later”. Would like to wait a bit before adding this and see 1 more complaint.

I think it’s safe to add this now… if a requires-login site is overloaded, adding more users isn’t going to improve things for them.

[sam (Sam Saffron)]

Sure … slotting to our next release