لقد كنت ألقي نظرة على أداء ملحق ActivityPub مؤخرًا وأفكر في أفضل الطرق لاختبار وإثبات الأداء بشكل موثوق لغرض مثل هذا المشروع. إليك بعض السياقات الأولية:
الملحق هو مشروع مفتوح المصدر يشارك فيه أطراف متعددة (أي Discourse، الذي يمتلك الملحق، و Pavilion الذي يقوم ببنائه حاليًا).
قد يكون لدى الأطراف المختلفة أدوات / أنظمة اختبار أداء داخلية مختلفة.
تستفيد المشاريع مفتوحة المصدر متعددة الأطراف من الأساليب المتاحة بشكل شائع للاختبار، وإثبات، أن شيئًا ما يعمل، أو في هذه الحالة، يؤدي بشكل موثوق.
تهتم Discourse (بشكل جدير بالثناء) بالأداء.
نعتقد في Discourse أن الأداء ميزة. نرحب بطلبات السحب التي تحسن أداء العميل أو الخادم.
حاليًا، الطريقة الوحيدة المتاحة بشكل شائع للاختبار / إثبات أداء الخادم في Discourse (على حد علمي) هي track_sql_queries، والتي تُستخدم عادةً (ولكن ليس حصريًا) في اختبارات الطلبات.
في حين أن عدد الاستعلامات هو مؤشر واحد على الأداء، إلا أنه ليس المؤشر الوحيد (بعض الاستعلامات أكبر من غيرها).
كمثال حديث على استخدام track_sql_queries انظر
إذا كنت على دراية بهذا المجال، فربما تعرف شيئًا مثل
القاعدة الأساسية هي أن اختبارات الوحدة تحتاج إلى السرعة واختبارات الأداء تحتاج إلى الوقت.
والذي، على ما يبدو، يمكن أن يجعل اختبار الأداء (بخلاف عد الاستعلامات) صعبًا إلى حد ما للدمج في مجموعة rspec (أو ما شابه). ومع ذلك، يحاول البعض
أنا مهتم بمعرفة الأساليب أو الاقتراحات أو الأفكار العملية الأخرى التي قد يمتلكها الزملاء لإضافة المزيد من اختبارات الأداء المتاحة بشكل شائع، وإثباتات الأداء، إلى نظام Discourse البيئي. أو إذا كانت هناك أساليب أو مناهج لم أذكرها هنا. أود التأكيد على كلمتي “عملي” و “متاح بشكل شائع” هناك.
أحد الأفكار التي تخطر ببالي هو أنه يمكن استخدام MiniProfiler في مواصفات، أي شيء مثل Rack::MiniProfiler.profile_singleton_method. لكنني لم أجرب ذلك، أو أعرف ما إذا كان ذلك سيكون فكرة جيدة.