jmeter - وحدة تحكم حلقة وفروق العد الفرز

لدي سيناريو بسيط:

  • log in
  • perform search1
  • perform search2
  • perform search3

الآن ، هل هناك فرق بين هذين النهجين

  1. 10 threads, 1 loop, login + loop controller (3 loops) for search
  2. 10 threads, 3 loops, once only controller for login + search

نظريًا ، يجب أن يكون السلوك هو نفسه ، بمعنى 10 مستخدمين يسجلون ويديرون ثلاث عمليات بحث ، أليس كذلك؟
أم أن هناك فرق؟
أي نهج أفضل؟

1

1 إجابة

لا فرق في قضيتك.

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

0
وأضاف
شكرا اليس. لذا قمت بتشغيل كلا الإصدارين من نفس السيناريو ويبدو أن النهج الثاني أبطأ بكثير من الأول. عدد الطلبات هو نفسه في كلتا الحالتين ، ولكن أوقات الاستجابة تكون أبطأ بكثير عندما يكون عدد الحلقات المجموعة لمؤشر الترابط أعلى من 1. يكون توزيع مؤشرات الترابط النشطة عبر الوقت متماثلاً إلى حد كبير. أي فكرة لماذا يعمل الإصدار الثاني أبطأ؟
وأضاف المؤلف tom, مصدر
كنت الحق في المرة الأولى. يبدو أن المشكلة قد تم تقديمها بواسطة عنصر ملف البيانات ، عندما تم تضمينها على المستوى المرتفع الذي كانت تعمل فيه للنهج الثاني ، ولكن أولها أخذ دائماً قيمة واحدة لوحدة تحكم الحلقة بأكملها ، أي. تم البحث 3 مرات لنفس القيمة. اضطررت إلى وضع CSV التكوين تحت وحدة تحكم حلقة لجعله يقرأ قيم مختلفة لكل عدد حلقة. خط Bootom. يجب أن يكون هناك اختلاف بسيط بين هذين النهجين. شكر!
وأضاف المؤلف tom, مصدر
بالنظر إلى مجموعة نتائج الاختبار التجريبي لكلا السيناريوهين ، لا أرى أي اختلاف في أوقات الاستجابة مع ذلك - قم بإحالة نتائج "تقرير التجميع" على سبيل المثال: متوسط ​​/ 90٪ لقيم خط/الإنتاجية على الأقل. يبدو أن ظهور مؤشرات الترابط النشطة على مدار الوقت أمر مختلف قليلاً - وهذا يعتمد أكثر على بنية السيناريو/الاختبار.
وأضاف المؤلف Aliaksandr Belik, مصدر