عندما يتطلب الموقع تسجيل الدخول، لا تُعرض لافتة "الموقع مثقل" حيث لا يوجد وصول مجهول

من حين لآخر، تظهر هذه الإشعارات في أعلى المنتدى:

بسبب الحمل الشديد، يتم عرض هذا مؤقتًا كما يراه المستخدم غير المسجل.

لديّ ملاحظات وأسئلة عدة حول هذا الأمر:

أولاً، لا يبدو أن الخادم يعاني من حمل شديد. آخر مرة رأيت فيها هذا التحذير، أظهرت مراقبة الخادم أن ذروة حمل المعالج كانت 24%، واستهلاك الذاكرة كان أعلى قليلاً من 50%، وما إلى ذلك. وإلى حد علمي، لم يكن هناك انخفاض ملحوظ في الأداء بالنسبة للمستخدمين. لذا أتساءل: ما هو الحد الفاصل لهذا التحذير، وهل هو مُعاير بشكل معقول؟

ثانيًا، والأهم بالنسبة لي، هو أن المنتدى الذي أديره خاص تمامًا. لا يستطيع المستخدمون غير المسجلين رؤية أي شيء سوى صفحة تسجيل الدخول. لذا فإن الإشعار غير دقيق، أي أن الصفحة ليست مُعروضة كما يراها المستخدم غير المسجل، لأن مثل هذا المستخدم لن يتمكن من رؤيتها على الإطلاق. وقد تسبّب هذا في حدوث بعض الارتباك في مناسبات عدة، حيث فُسر على أنه يعني أن منشورات منتدى الخاص أصبحت فجأة متاحة للمستخدمين غير المصرح لهم. لقد شعرتُ بالقلق الشديد في المرة الأولى التي رأيتُ فيها هذا الإشعار، ومن حين لآخر أتلقى أسئلة من المستخدمين بشأنه.

ربما ينبغي إعادة صياغة هذا التحذير؟ أو تغييره/تعطيله للمنتديات الخاصة؟

هل من الممكن تعطيله لمنتدى معين؟

3 إعجابات

مرحبًا @meriksson

ملاحظة: يتم تفعيل هذا الإشعار عبر ملف تعريف ارتباط (cookie):

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

مرجع:

البحث عن هذا الملف التعريفي للارتباط على GitHub يُظهر:

حيث يُوجد force_anon هنا:

 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

مرجع:

انظر أيضًا:

 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
4 إعجابات

هذه نقطة جيدة يا @sam، ففي موقع خاص تمامًا، قد يكون النص المحفوظ مربكًا… وربما غير صحيح.

4 إعجابات

يظهر هذا التحذير عندما يقوم NGINX بإرسال طلب إلى Unicorn (خادم التطبيق) ونلاحظ تأخراً كبيراً.

على سبيل المثال (مبالغ فيه):

  • يقول NGINX: … مرحباً، إليك طلباً تلقيته من مستخدم في الساعة 1 ظهراً
  • يمرّ ساعة
  • يستلم خادم التطبيق الطلب … يا إلهي، استغرق الأمر ساعة حتى يصل إليّ… يجب أن أكون مثقلاً.

يمكنك التحكم في الحد الفاصل من خلال الإعدادين التاليين:

DISCOURSE_FORCE_ANONYMOUS_MIN_QUEUE_SECONDS و DISCOURSE_FORCE_ANONYMOUS_MIN_PER_10_SECONDS

والأهم من ذلك، إذا كان خادمك يمتلك سعة إضافية كبيرة، أضف المزيد من عمليات Unicorn عن طريق زيادة UNICORN_WORKERS.

إذا كان الموقع يتطلب تسجيل دخول، فربما يجب أن نغير التحذير إلى شيء أكثر خطورة (شاشة زرقاء، أنت مقيد بالمعدل).

هذه هي المرة الأولى التي أسمع فيها عن موقع يتطلب تسجيل دخول يصل إلى هذا الحد من معدل الاستخدام. أتفق على أنه يجب أن نتحسن قليلاً في هذا الشأن.

4 إعجابات

سأنتظر هنا حتى تصل شكوى مستقلة أخرى.

أفضل ما يمكننا فعله تحت الحمل الشديد، للمواقع التي “تتطلب تسجيل الدخول”، هو ببساطة عرض شاشة زرقاء تقول “الموقع مثقل، حاول مرة أخرى لاحقًا”. نود الانتظار قليلاً قبل إضافة هذا والإبلاغ عن شكوى أخرى.

3 إعجابات

يحدث هذا في مجتمع Discourse خاص وصغير جدًا أزوره بشكل متكرر. ظهر لي خطأ 502 bad gateway من nginx، ثم لم يعد الموقع يعمل على الإطلاق. في النهاية، تم تحميله، لكنه عرض لي رسالة اللافتة المذكورة أعلاه.

إعجاب واحد (1)

أعتقد أنه من الآمن إضافة هذا الآن.. إذا كان موقع يتطلب تسجيل الدخول مثقلًا، فإن إضافة مستخدمين آخرين لن يحسن الأمور بالنسبة لهم.

3 إعجابات

بالتأكيد… سنقوم بتضمينه في إصدارنا القادم

3 إعجابات