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

مطور
1

So here is my issue. I have a requirement to essentially seed a Discourse production instance with around 200 posts at a time from a plugin admin action. These posts will be ‘created by’ 1 of 10 different regular users. The reason it’s a plugin action is because the users of this particular instance have a team of moderators they want to train up, and wanted some test posts to train them on, and the ability to seed more when they need them.

I got this working fine by passing skip_validations: true to PostCreator.new, however now there’s a requirement that some of the created posts are also flagged.

I’m using PostActionCreator.create to flag some of these posts, but now I’m getting hit by the rate limiter here: https://github.com/discourse/discourse/blob/ad7a13921f2af8c792530c84386b64911c8e7ea2/lib/post_action_creator.rb#L69

I first attempted to disable the RateLimiter but that was causing my action to crash the server process eventually, possibly when I was trying to turn it back on, and then I realised it probably wasn’t a good idea anyway.

So my question is, is there a better way to bypass the rate limiter when running some arbitrary code i.e. something like:

RateLimiter.bypass do
# run some code not affected by the rate limiter
end

Or do I need to basically just need to copy most of what the PostActionCreator is doing but leave out the troublesome line?

Any help would be greatly appreciated! I’m still absorbing a lot of the Discourse code so I’m aware I’ve probably missed something that makes this a lot easier!

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

What I’d likely do is run a script in the Rails console. Have you checked out: Global rate limits and throttling in Discourse? It looks like you can change those rate limits.

إعجابَين (2)
3

This isn’t really a path I want to go down as I want it to initiated by users rather than them relying on me to run a script in the console.

3 إعجابات
4

Did you look at the link about changing the rate limits?

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 للحصول على محرر.

إعجابَين (2)
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 وترى ما إذا كانت عددًا صحيحًا

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

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

limit = GlobalSetting.max_admin_api_reqs_per_minute.to_i

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

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

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

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

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

14

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

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

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

16

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

17

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

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

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

19

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

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

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

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

user_avatars
user_emails
user_profiles
user_search_data
user_stats
users
إعجاب واحد (1)