هل هناك طريقة لإيقاف مؤقت لـ RateLimiter مؤقتًا لإنشاء جماعي بواسطة المشرف؟

مطور
1

إذن، هذه هي مشكلتي. لدي مطلب يتمثل في ملء (seeding) مثيل Discourse الإنتاجي بما يقارب 200 منشور في كل مرة عبر إجراء إداري في إضافة (plugin). سيتم «إنشاء» هذه المنشورات بواسطة واحد من بين 10 مستخدمين عاديين مختلفين. السبب في أن هذا إجراء في إضافة هو أن مستخدمي هذه الحالة الخاصة لديهم فريق من المشرفين يريدون تدريبهم، ويريدون بعض منشورات الاختبار للتدريب عليها، مع إمكانية إضافة المزيد عند الحاجة.

نجحت في جعل هذا يعمل بشكل صحيح عن طريق تمرير skip_validations: true إلى PostCreator.new، ولكن الآن هناك مطلب بأن بعض المنشورات المُنشأة يتم أيضًا وضع علامة عليها (flag).

أستخدم PostActionCreator.create لوضع علامة على بعض هذه المنشورات، لكنني الآن أواجه حد المعدل (rate limiter) هنا: discourse/lib/post_action_creator.rb at ad7a13921f2af8c792530c84386b64911c8e7ea2 · discourse/discourse · GitHub

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

إذن سؤالي هو: هل هناك طريقة أفضل لتجاوز حد المعدل عند تشغيل بعض الأكواد العشوائية، أي شيء من هذا القبيل:

RateLimiter.bypass do
# تشغيل بعض الأكواد غير المتأثرة بحد المعدل
end

أم أنني بحاجة ببساطة إلى نسخ معظم ما يفعله PostActionCreator ولكن باستثناء السطر المزعج؟

أي مساعدة ستكون محل تقدير كبير! ما زلت أمتص الكثير من كود Discourse، لذا أنا أدرك أنني ربما أغفلت شيئًا يجعل الأمر أسهل بكثير!

2

ما من المرجح أن أفعله هو تشغيل سكريبت في وحدة تحكم Rails. هل قمت بمراجعة: https://meta.discourse.org/t/global-rate-limits-and-throttling-in-discourse/78612؟ يبدو أنه يمكنك تغيير حدود المعدل تلك.

3

هذه ليست المسار الذي أرغب في اتباعه، إذ أريد أن يتم تفعيله من قبل المستخدمين بدلاً من الاعتماد عليّ لتشغيل سكريبت في وحدة التحكم.

4

هل نظرت في الرابط المتعلق بتغيير حدود المعدل؟

5

هل توصلت إلى حل؟ تعديل ملف yaml ليس مثاليًا لأنه يتطلب إعادة بناء. لست على دراية كافية بـ rails/discourse لمعرفة كيفية تعطيله مؤقتًا في وحدة التحكم.

6

ما هي حالة الاستخدام الخاصة بك؟ ما هي المشكلة التي تحاول حلها والتي تقف فيها حدود المعدل عقبة أمامها؟

7

محاولة استيراد 60 ألف مستخدم عبر واجهة برمجة التطبيقات (API) بأسرع ما يمكن دون إعادة بناء. لقد حاولت أيضًا في تثبيت اختباري زيادة حد واجهة برمجة التطبيقات (API) للمسؤول عبر YAML، لكن يبدو أنها لم تنجح، ربما فعلت شيئًا خاطئًا. (أقوم بتشغيل عمليات الاستيراد على الحاوية، لذا لا ينبغي أن ينطبق تحديد المعدل عبر HTTP).

8

هذا ليس مفيدًا جدًا، ولكن ما سأفعله هو إنشاء المستخدمين في Rails بدلاً من ذلك عبر واجهة برمجة التطبيقات. discourse/script/import_scripts/csv_importer.rb at main · discourse/discourse · GitHub يمكن أن يكون بداية.

ولكن يمكنك الدخول إلى الحاوية وتعديل /var/www/discourse/config/discourse.conf وتعيين تلك المتغيرات هناك ثم القيام بـ sv restart unicorn (أو ربما sv reload unicorn). ستحتاج على الأرجح إلى القيام بشيء مثل apt-get update; apt-get install -y vim للحصول على محرر.

9

غريب. عندما أقوم بعرض ملف الإعدادات، تم تعيين الحد الجديد بالفعل. لذا نجح تحديث YAML:

max_admin_api_reqs_per_key_per_minute = '6000'

لكنه لا يبدو أنه يعمل. لا يزال هناك حد أقصى يبلغ 60 في الدقيقة. عندما أقوم بتقييد الطلبات إلى 60 في الدقيقة، يمر معظمها ولكن بسبب الارتجاج، لا يزال عدد قليل منها يؤدي إلى تشغيل محدد المعدل:

{'success': True, 'active': True, 'message': 'Your account is activated and ready to use.', 'user_id': 3596}
{'success': False, 'message': ' New registrations are not allowed from your IP address (maximum limit reached). Contact a staff member.', 'errors': {'ip_address': ['New registrations are not allowed from your IP address (maximum limit reached). Contact a staff member.']}, 'values': {'name': None, 'username': 'asdfd', 'email': 'user@domain.com'}, 'is_developer': False}
{'success': True, 'active': True, 'message': 'Your account is activated and ready to use.', 'user_id': 3597}
10

أتساءل عما إذا كانت المشكلة تتعلق بعلامات الاقتباس؟

قد تتحقق من SiteSettings.max_admin_api_reqs_per_key_per_minute وترى ما إذا كانت عددًا صحيحًا

11

in default_current_user_provider.rb (الملف الوحيد الذي وجدته والذي يبدو أنه يشير إلى هذه القيمة، يحتوي على:

limit = GlobalSetting.max_admin_api_reqs_per_minute.to_i

لذا يبدو أنه يقوم بتحويلها. لقد حاولت حتى استبدالها برقم في الكود.

12

تباً. كنت أخشى ذلك.

13

أعتقد أن الأمر يتعلق بحد آخر: أعتقد أنه الحد الأقصى للتسجيلات من عنوان IP الذي يصل إليه، لكنني لا أفهم لماذا لا يتم حظره بشكل دائم بعد الوصول إليه. ربما يكون هناك خطأ في حد البريد العشوائي هذا؟

14

إذا كان لدى هؤلاء المستخدمين جميعًا نفس عنوان IP، فأنا أراهن أنك على حق. أعتقد أن الحل هو تغيير هذا الإعداد أو منح الأشخاص عناوين IP وهمية مثل 127.0.0.x (أو ربما استخدام IPv6 لتسهيل الأمر؟)

15

أعتقد أنه يكتشف من أين تم تقديم الطلب (الكمبيوتر المضيف) ولكني أستطيع التحايل عليه عن طريق إضافة مستخدم TL2 على نفس عنوان IP (أو تعديل حد IP).

16

واجهة برمجة تطبيقات المستخدم بطيئة جدًا، مع ذلك.

17

ولهذا السبب أوصي بالقيام بذلك في rails. من المحتمل أن يقوم بحوالي 500/دقيقة.

18

نعم، سأجرب ذلك. لكنني لست متأكدًا من كيفية تشغيل البرنامج النصي، وأين يجب أن أنسخه وإلى أين يجب أن أنفذه (بمجرد وضع ملف CSV في الأماكن الصحيحة)؟

19

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

20

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

كان هناك موضوع يسأل عن الجداول المطلوبة، وقد تم إغلاقه الآن، لذا سأجيب هنا بأنني قمت بتغيير الجداول التالية لإدراج المستخدمين:

user_avatars
user_emails
user_profiles
user_search_data
user_stats
users