چوٹی کی تیاری کے لیے کام کا خودکار ماڈل کیسے بنایا جائے۔

اگر آپ نے کبھی بھی APM ٹول سے اس سوال کا جواب دینے کے لیے دو دن گزارے ہیں کہ "مجھے کتنے ورچوئل صارفین کو لوڈ ٹیسٹ میں چلنا چاہیے؟”، تو یہ ٹیوٹوریل آپ کے لیے ہے۔

آخر میں، آپ دیکھیں گے کہ کسی بھی چیز کا اندازہ لگائے بغیر، 5 منٹ سے بھی کم وقت میں براہ راست پروڈکشن ٹیلی میٹری سے اپنے کام کے بوجھ کے ماڈل کے تمام نمبر کیسے حاصل کیے جائیں۔

ہمارے استعمال کے معاملات:

ہر سال، بلیک فرائیڈے سے صرف چند ہفتے پہلے، کارکردگی کے انجینئرز اور SREs کو ایک جیسے چیلنجز کا سامنا کرنا پڑتا ہے۔ کسی کو چوٹی کے موسم کے بوجھ کی جانچ کے لیے کام کے بوجھ کے ماڈل کی ضرورت ہے اور گھڑی ٹک ٹک کر رہی ہے۔

ایک عام طریقہ یہ ہے کہ آپ اپنے APM ٹول میں لاگ ان کریں، CSV ایکسپورٹ کریں، ڈیٹا کو اسپریڈ شیٹ میں محور کریں، اور صارف کے بہاؤ کے بارے میں ایک تعلیم یافتہ اندازہ لگائیں۔ اس میں دن لگتے ہیں، متعدد افراد شامل ہوتے ہیں، اور نتائج اکثر اب بھی غلط ہوتے ہیں۔

یہ ٹیوٹوریل آپ کو ایک خودکار طریقہ کار سے گزرتا ہے جو پورے عمل کو براہ راست مشاہداتی سوالات سے بدل دیتا ہے۔ میں تمام مراحل کو ظاہر کرنے کے لیے New Relic (NRQL) اور Dynatrace (USQL) کا استعمال کروں گا، لیکن یہ نقطہ نظر کسی بھی APM پلیٹ فارم کے ساتھ کام کرتا ہے جو سیشن اور لین دین کے ڈیٹا کو ظاہر کرتا ہے۔

ہم نے جاوا اسپرنگ بوٹ ٹول بھی بنایا ہے جسے Peak Workload Analyzer کہا جاتا ہے جو خود بخود ان تمام سوالات کو چلاتا ہے اگر آپ سیدھے آؤٹ پٹ پر جانا چاہتے ہیں۔

انڈیکس

شرائط

اس ٹیوٹوریل پر عمل کرنے سے پہلے آپ کو ضرورت ہو گی:

• آپ کی درخواست پر براؤزر اور/یا APM آلات کے ساتھ ایک نیا Relic یا Dynatrace اکاؤنٹ فعال ہے۔

• جاوا 11 یا اس سے زیادہ انسٹال ہے۔

• Maven 3.6 یا اس سے زیادہ انسٹال کریں۔

• کم از کم 30 دنوں کی پروڈکشن ٹریفک ہسٹری ونڈو، بشمول معلوم چوٹی کے ادوار (مثلاً گزشتہ سال بلیک فرائیڈے)

اس ٹیوٹوریل میں دو تصورات ظاہر ہوتے ہیں اور پہلے سے سمجھنے کے قابل ہیں۔

• درخواستیں فی سیکنڈ (RPS): ایپلیکیشن کو فی سیکنڈ موصول ہونے والی HTTP درخواستوں کی تعداد۔ یہ بنیادی لوڈ ٹیسٹ کا مضمون ہوگا۔

• سیشن: یہ تب ہوتا ہے جب کوئی ایک صارف آپ کی درخواست کو پہلے صفحہ سے آخری صفحہ تک مسلسل دیکھتا ہے۔ سیشن کی گنتی اور دورانیہ کنکرنٹ یوزرز فارمولے کی بنیاد ہیں۔

دستی ورک لوڈ ماڈلنگ کے چیلنجز

اس نقطہ نظر کی قدر کو سمجھنے کے لیے، یہ نقشہ بنانے میں مدد کرتا ہے کہ ایک عام دستی کام کا بوجھ ماڈلنگ مشق عملی طور پر کیسی دکھتی ہے۔

دستی کام	ملوث لوگ	عام وقت	غلطی کا خطرہ
اپنے APM ٹول میں لاگ ان کریں، صحیح ایپلیکیشن پر جائیں، تاریخ کی حدود مقرر کریں، اور ٹائم زون کے مسائل کو ہینڈل کریں۔	ایس آر ای / پرفارمنس انجینئرنگ	30 ~ 60 منٹ	درمیانی غلط ایپ یا ٹائم زون
اپنے مصروف ترین دنوں کو بصری طور پر پہچاننے کے لیے ٹریفک گراف کو دستی طور پر اسکرول کریں۔	ایس آر ای / پرفارمنس انجینئرنگ	45~90 منٹ	اعلی آنکھ سچی چوٹی کی آرزو کرتی ہے۔
CSV میں فی گھنٹہ ڈیٹا ایکسپورٹ کریں اور بہترین اوقات تلاش کرنے کے لیے Excel میں پیوٹ کریں۔	کارکردگی انجینئر	1~2 گھنٹے	اعلی برآمد کی حد، محور کی خرابی۔
APM ٹرانزیکشن لسٹ میں سرفہرست لین دین کی دستی طور پر شناخت کریں۔	کارکردگی انجینئرنگ + ترقی	2 ~ 3 گھنٹے	اعلی کوئی فیصد وزن نہیں ہے۔
صارف کے سفر کے بہاؤ کی تشکیل نو کے لیے ڈویلپرز اور پروڈکٹ کے مالکان کا انٹرویو کریں۔	پرفارمنس انجینئرنگ + بیچلر + ڈویلپر	4-8 گھنٹے	بہت اعلیٰ۔ رائے پر مبنی
دستی اسپریڈشیٹ فارمولوں کا استعمال کرتے ہوئے سیشنز کی تعداد سے ہم آہنگ صارفین کا اندازہ لگائیں۔	کارکردگی انجینئر	1~2 گھنٹے	اعلی لٹل کا قانون شاذ و نادر ہی لاگو ہوتا ہے۔
SLA دستاویزات یا ماضی کے واقعات کی ٹیم میموری کی بنیاد پر SLA کی حدیں سیٹ کریں۔	پرفارمنس انجینئرنگ + آرکیٹیکٹ	1~2 گھنٹے	درمیانی دستاویزات اکثر پرانی ہو جاتی ہیں۔
ایک ورک لوڈ ماڈل دستاویز بنائیں اور اسٹیک ہولڈر کی منظوری حاصل کریں۔	پرفارمنس انجینئر + مینیجر	3-4 گھنٹے	درمیانی نظر ثانی سائیکل
بندوق	2 ~ 4 لوگ	13-22 گھنٹے	مجموعی طور پر بہت زیادہ

اس 13-22 گھنٹے کے تخمینے میں جائزہ لینے کے چکر، APM تک رسائی کے لیے انتظار کا وقت، یا ناگزیر "ہمیں اسے دوبارہ کرنے کی ضرورت ہے کیونکہ تاریخ کی حد غلط ہے” لمحہ جس کا تقریباً ہر ٹیم تجربہ کرتی ہے۔

درحقیقت، زیادہ تر تنظیمیں کام کے بوجھ کے ماڈل کی تعمیر میں پورے ہفتے کے برابر خرچ کرتی ہیں، صرف لوڈ ٹیسٹنگ کے دوران یہ دریافت کرنے کے لیے کہ ان کے منظر نامے کا وزن ابھی بھی غلط ہے۔

انجینئرنگ کے وقت کے علاوہ، دستی کام کے بوجھ کے ماڈلز براہ راست کاروباری خطرہ بھی رکھتے ہیں۔ وہ ماڈل جو چوٹی کی ٹریفک کو کم سمجھتے ہیں وہ کم انتظامات کا باعث بنتے ہیں۔ غلط صارف کے سفر کے مفروضوں پر مبنی ماڈل کم اثر والے بہاؤ پر بوجھ کی جانچ کی صلاحیت کو ضائع کرتے ہیں۔

دونوں نتائج کا مطلب ہے کہ بلیک فرائیڈے کی تیاریاں قیاس آرائیوں پر مبنی ہیں اور یہ کہ خطرات بدترین ممکنہ لمحے تک خود کو پیش نہیں کرتے ہیں۔

خودکار نقطہ نظر: کیا بدلا ہے؟

اس مقالے میں طریقہ کار مندرجہ بالا تمام دستی اقدامات کو براہ راست اور دوبارہ پیدا کرنے کے قابل مشاہداتی سوالات سے بدل دیتا ہے۔ یہاں سرگرمیوں کی وہی فہرست ہے، جو ایک خودکار نقطہ نظر کے لیے دوبارہ لکھی گئی ہے:

خودکار کام	ملوث لوگ	وقت لیا	درستگی
چوٹی ورک لوڈ تجزیہ کار: تاریخ کی حد درج کریں، ایپ کا نام منتخب کریں، اور چلائیں پر کلک کریں۔	تمام انجینئرز	2 منٹ کا سیٹ اپ	درست ڈیٹا پر مبنی
ایپ خود بخود چوٹی کے دن کے سوالات چلاتی ہے۔	خودکار	خودکار	درست ٹیلی میٹری سے
ایپ خود بخود چوٹی گھنٹے اور چوٹی منٹ کے سوالات چلاتی ہے۔	خودکار	خودکار	درست 1 منٹ تک بالٹی
ایپ خود بخود منظر نامے کی ملاوٹ اور فنل کے سوالات چلاتی ہے۔	خودکار	خودکار	درست پیداوار کی تقسیم
ایپ خود بخود VU شمار کے لیے سیشن فارمولے کا اطلاق کرتی ہے۔	خودکار	خودکار	اعلی ریاضی سے ماخوذ
ایپ خود بخود صارف کے سفر اور نتائج کا وزن بناتی ہے۔	خودکار	خودکار	درست سیشن ڈیٹا سے
انٹرایکٹو HTML ڈیش بورڈز اور ایکسپورٹ کرنے کے قابل JSON رپورٹس بنائیں	خودکار	خودکار	اعلی مکمل طور پر ٹریس ایبل
بندوق	1 شخص	5 منٹ سے کم	اعلی ثبوت پر مبنی

چوٹی ورک لوڈ اینالائزر خود بخود مکمل اینالیٹکس ڈیش بورڈز اور JSON رپورٹس تیار کرتا ہے، اس کام کو کم کرتا ہے جس میں بصورت دیگر 13 سے 22 انسانی انجینئرز کو 5 منٹ سے بھی کم وقت لگے گا، فی چوٹی کی تیاری کے چکر میں 99% کمی۔ کوئی استفسار تحریر، اسپریڈشیٹ، یا دستی حساب کتاب نہیں۔

اس مضمون کا سیکشن 1 چوٹی کے کام کے بوجھ کے تجزیہ کی ایپلی کیشن کو متعارف کرایا گیا ہے۔ بقیہ حصے مجموعی تکنیکی نفاذ کی دستاویز کرتے ہیں: درخواست کے ہر قدم پر درست سوالات، لاگو فارمولے، اور ہر فیصلے کے پیچھے منطق۔

یہ ان انجینئرز کے لیے ایک تکنیکی حوالہ کے طور پر کام کرتا ہے جو یہ سمجھنا چاہتے ہیں کہ ٹول ہڈ کے نیچے کیا کرتا ہے، اور ان ٹیموں کے لیے ایک اسٹینڈ اسٹون طریقہ کار گائیڈ جو اپنے سوالات چلانا چاہتی ہیں۔

1. چوٹی ورک لوڈ تجزیہ کار

چوٹی ورک لوڈ اینالائزر ایک جاوا اسپرنگ بوٹ ایپلی کیشن ہے جو ایک ہی کمانڈ میں مکمل طور پر خودکار ورک لوڈ ماڈل طریقہ کار کو نافذ کرتی ہے۔

نیو ریلیک یا ڈائنٹریس سے براہ راست جڑیں، تمام چھ سوالات کے مراحل کو خود بخود چلائیں، ہم آہنگی استعمال کنندگان کی گنتی کریں، صارف کے سفر کی شناخت کریں، اور دستی استفسار تحریر کی ضرورت کے بغیر قابل برآمد JSON نتائج کے ساتھ انٹرایکٹو، ریئل ٹائم ڈیش بورڈز بنائیں۔

1.1 فوری آغاز

# 1. Build the project
mvn clean package

# 2. Start the web server
java -jar target/peak-workload-analyzer-1.0.0.jar

# 3. Open browser
open http://localhost:8080

# 4. Select provider tab: New Relic or Dynatrace
# 5. Enter API credentials
# 6. Select application and set date range
# 7. Click Run Analysis

1.2 درخواست خود بخود کیا کرتی ہے۔

خودکار اقدامات	طریقہ کار کے مراحل	حساب	دستاویز کے حصے سے مماثل ہے۔
چوٹی کے دن کے سوالات چلائیں۔	مرحلہ 1	چوٹی کا موسم	سیکشن 3
چوٹی کے اوقات کے سوالات چلائیں۔	مرحلہ 2	چوٹی کا وقت	سیکشن 4
چوٹی منٹ چلائیں اور RPS حاصل کریں۔	مرحلہ 3	ہدف آر پی ایس	سیکشن 5
منظرنامے مکس کریں اور فنل کے سوالات چلائیں۔	مرحلہ 4	فیصد وزن	سیکشن 6
سیشن فارمولوں کے ذریعے ہم وقتی صارفین کا حساب لگائیں۔	مرحلہ 5	VUs کی تعداد	سیکشن 7
پروفائلنگ فعال سیشن اور VU پول کی حدود	مرحلہ 6	VU پول	دفعہ 8
انٹرایکٹو HTML ڈیش بورڈز اور ایکسپورٹ کرنے کے قابل JSON رپورٹس بنائیں	حساب	HTML ڈیش بورڈ اور JSON	سیکشن 9

1.3 آؤٹ پٹ فائل

output/
├── peak-analysis-report.json    # All metrics in structured JSON
├── peak-analysis-report.html    # Interactive dashboard (12 widgets)
├── user-journeys.json           # Top user flows with % weights
└── logs/
    └── analysis.log

GitHub ذخیرہ: کام کا بوجھ تجزیہ کرنے والا چوٹی۔ آپ اس کی پیروی کرنے کے لیے کلون کر سکتے ہیں یا اسے حوالہ کے نفاذ کے طور پر استعمال کر سکتے ہیں۔

اگر آپ ایپلیکیشن کو استعمال کرنے کے بجائے خود استفسار کرنا چاہتے ہیں، تو سیکشن 3 کا ہر سیکشن بالکل وہی کچھ دستاویز کرتا ہے جو ایپلیکیشن کرتی ہے، تبصروں کے ساتھ منطق اور متوقع آؤٹ پٹ کی وضاحت کرتے ہیں۔

2. طریقہ کار کا جائزہ

خودکار کام کا بوجھ ماڈل چھ قدمی ڈرل ڈاؤن پائپ لائن کی پیروی کرتا ہے۔ صارف ایک ہسٹری ونڈو فراہم کرتا ہے، اور استفسار آہستہ آہستہ تفصیل کی ہر سطح پر عین بدترین صورت حال تک محدود ہو جاتا ہے۔

نیچے دیا گیا خاکہ چھ مراحل اور ان کی بنیادی پیداوار کو دکھاتا ہے۔

6 مرحلہ پائپ لائن: پِیک ڈے → پِیک آورز → پِیک منٹس → مکس آف سیناریوز → کنکرنٹ صارفین → فعال سیشنز۔ پروڈکشن ٹیلی میٹری سے لوڈ ٹیسٹ کے پیرامیٹرز حاصل کرنے کے لیے ہر مرحلہ درج ذیل اقدامات فراہم کرتا ہے:

2.1 ہر مرحلے پر کلیدی اشارے

قدم	بنیادی میٹرکس	ثانوی میٹرکس	کیا استعمال کرنا ہے
چوٹی کا موسم	فی کیلنڈر دن درخواستوں کی کل تعداد	منفرد سیشنز، اوسط جوابی وقت	تمام بعد کے سوالات کے لیے دائرہ کار کی وضاحت کریں۔
چوٹی کا وقت	فی گھنٹہ فی بالٹی درخواستیں۔	P50/P95/P99 اسٹینڈ بائی ٹائم فی گھنٹہ	ٹیسٹ پیریڈ ونڈو لوڈ کریں۔
چوٹی منٹ	60 سیکنڈ ونڈو میں زیادہ سے زیادہ درخواستیں۔	زیادہ سے زیادہ RPS = شمار / 60	ٹیسٹ آر پی ایس گولز لوڈ کریں۔
منظر نامے کا مرکب	ہر ٹرانزیکشن کی قسم کا % حصہ	P95 فی منظر نامے، سٹاپ فینل	وزنی لوڈ ٹیسٹ کا منظرنامہ
ہم آہنگی	(گھنٹہ کے سیشن × اوسط سیشن کا دورانیہ سیکنڈ) / 3600	سیشن کا دورانیہ، صفحات/سیشن	لوڈ ٹیسٹ انجن میں VUs کی تعداد
فعال سیشن	چوٹی منٹ کی الگ گنتی (سیشن)	نیا بمقابلہ واپسی تقسیم، باؤنس ریٹ	کل VU پول کا سائز

2.2 ترقی کے عوامل کا اطلاق

پیداوار ٹیلی میٹری پچھلے سال کی چوٹی کو ظاہر کر سکتی ہے، لیکن اس سال کی چوٹی تقریبا یقینی طور پر زیادہ ہوگی۔

نمو کا عنصر ایک ضرب ہے جسے آپ پچھلے سال کے نمبروں پر لاگو کرتے ہیں تاکہ یہ طے کیا جا سکے کہ متوقع نمو کے لیے کتنا ٹیسٹ لوڈ کرنا ہے، اس لیے آپ جانچ کر رہے ہیں کہ آپ کا ٹریفک کہاں جا رہا ہے، نہ کہ وہ کہاں ہے۔

اپنی ٹریفک کی رفتار کی بنیاد پر ایک ضرب کا انتخاب کریں۔

• 1.2 بار: قدامت پسند – قائم پلیٹ فارم، بالغ مارکیٹ

• 1.3 بار: اعتدال پسند—حاصل شدہ فعال صارفین، نئی منڈیاں

• 1.5 بار: جارحانہ – حالیہ مصنوعات کی شروعات، مارکیٹنگ کی مہمات

• 2.0x: تناؤ کی حدیں – بدترین صورت، اپنے بنیادی ڈھانچے کی حدود کو دریافت کرنا

مکمل لوڈ ٹیسٹ کا فارمولا یہ ہے: لوڈ ٹیسٹ ٹارگٹ RPS = زیادہ سے زیادہ RPS فی منٹ x گروتھ فیکٹر x سیفٹی بفر (1.1)

1.1 سیفٹی بفر نمو ایڈجسٹمنٹ کے ہدف سے 10% ہیڈ روم کا اضافہ کرتا ہے تاکہ ٹریفک میں اضافے کے لیے زیادہ سے زیادہ منٹوں میں جو اوسط حاصل نہ کر سکے۔

3. مرحلہ 1 – چوٹی کے دنوں کی شناخت کریں۔

یہ استفسار تاریخی مدت کے دوران فی کیلنڈر دن کی کل درخواستوں کو جمع کرتا ہے۔ سب سے زیادہ تھرو پٹ والا دن چوٹی کا دن بن جاتا ہے اور اس کے بعد کے تمام سوالات کو منجمد کر دیتا ہے۔

یوزر ان پٹ: شروع اور اختتامی تاریخوں کی ضرورت ہوتی ہے جس میں پچھلے سال کے لیے معلوم چوٹی کے ادوار شامل ہوتے ہیں۔ مثال: 15 نومبر 2025 سے 15 دسمبر 2025 تک۔

3.1 نیا نمونہ – NRQL

نیو ریلک آپ کی ایپلیکیشن کی ٹیلی میٹری کو ایونٹ کے ڈیٹا کے طور پر اسٹور کرتا ہے جس سے NRQL کے ساتھ استفسار کیا جا سکتا ہے، ایک SQL جیسی استفسار کی زبان۔

چوٹی کی تاریخیں تلاش کرنے کے لیے، پورے تاریخی دور سے استفسار کریں اور کیلنڈر کی تاریخ کے حساب سے درخواستوں کی تعداد کو جمع کریں۔

نیو ریلیک دو متعلقہ ڈیٹا ذرائع کو حاصل کرتا ہے: براؤزر کا ڈیٹا (صفحہ دیکھنے کے واقعات، براؤزر میں حقیقی صارفین کا کیا تجربہ ہوتا ہے) اور APM ڈیٹا (لین دین کے واقعات، سرور کیا عمل کرتا ہے)۔

ذیل میں دو سوالات ہر ایک ذریعہ کو صارف کے نقطہ نظر سے مصروف ترین دنوں کے طور پر چیک کرتے ہیں اور سرور کے نقطہ نظر سے مماثل ہونا چاہئے اور کسی بھی تضاد کی تحقیقات کے قابل ہیں۔

3.1.1 یومیہ براؤزر پیج ویوز

-- Step 1a: Peak Day — Browser PageView data
-- Run in: New Relic One > Query your data > Query Builder
 
SELECT
  count(*) AS total_page_views,
  uniqueCount(session) AS unique_sessions,
  average(duration) AS avg_load_ms,
  percentile(duration, 95) AS p95_load_ms
FROM PageView
WHERE appName="your-app-name"
FACET dateOf(timestamp)
SINCE '2025-11-15 00:00:00'
UNTIL '2025-12-15 23:59:59'
LIMIT 60
-- Note: Omit ORDER BY — uniqueCount(session) prevents ORDER BY on PageView.
-- Click the total_page_views column header in Query Builder to sort descending.

3.1.2 روزانہ APM لین دین

-- Step 1b: Peak Day — APM Transaction data (server-side / SPA)
 
SELECT
  count(*) AS apm_transactions,
  rate(count(*), 1 minute) AS avg_rpm,
  average(duration) AS avg_response_sec,
  percentile(duration, 95) AS p95_response_sec,
  filter(count(*), WHERE error IS TRUE) AS error_count
FROM Transaction
WHERE
  appName="your-app-name"
  AND transactionType="Web"
FACET dateOf(timestamp)
SINCE '2025-11-15 00:00:00'
UNTIL '2025-12-15 23:59:59'
LIMIT 60

3.2 Dynatrace – USQL

Dynatrace سیشن کی سطح پر اسی مسئلے سے رجوع کرتا ہے۔ یوزر سیشن کوئری لینگویج (یو ایس کیو ایل) یوزر سیشن اداروں سے استفسار کرتی ہے۔ یہاں، ہر قطار صارف کے ایک مکمل دورے کی نمائندگی کرتی ہے۔ انفرادی درخواستوں کو شمار کرنے کے بجائے، ہم مصروف ترین درخواستوں کو تلاش کرنے کے لیے سیشنز اور یومیہ صارف کی کل سرگرمیاں جمع کرتے ہیں۔

نیچے دی گئی استفسار کیلنڈر کی تاریخ کے لحاظ سے سیشنز کو گروپ کرتی ہے اور کاموں کی کل تعداد کے حساب سے آرڈر کرتی ہے، جس میں چوٹی کے دن ہوتے ہیں۔

// Step 1 — Dynatrace USQL: Peak day from user sessions
 
SELECT
  DATE(startTime)          AS calendar_day,
  COUNT(*)                 AS session_count,
  SUM(userActionCount)     AS total_actions,
  AVG(duration)            AS avg_session_ms
FROM usersession
WHERE
  startTime > '2025-11-15T00:00:00'
  AND startTime < '2025-12-15T23:59:59'
  AND applicationType="BROWSER"
GROUP BY DATE(startTime)
ORDER BY total_actions DESC

نیچے دیا گیا ڈیش بورڈ اس استفسار کا آؤٹ پٹ دکھاتا ہے جیسا کہ چوٹی ورک لوڈ تجزیہ کار نے پیش کیا ہے۔ سب سے اوپر سمری کارڈ چوٹی کی تاریخوں اور ان سے متعلقہ ہیڈ لائن میٹرکس کی نشاندہی کرتا ہے، ایک بار چارٹ پورے 30 دن کی ونڈو کے لیے درخواست کا حجم دکھاتا ہے جس میں چوٹی کی تاریخوں کو نمایاں کیا گیا ہے، اور ایک ٹیبل اوپر پانچ دنوں کی درجہ بندی کرتا ہے تاکہ آپ دیکھ سکیں کہ آس پاس کے دنوں کے مقابلے چوٹی کتنی صاف ہے۔

4. مرحلہ 2 – چوٹی کے اوقات کا تجزیہ

یہ استفسار، چوٹی کے دنوں تک دائرہ کار، ٹریفک کو گھنٹہ کے وقفوں میں ڈال دیتا ہے۔ مصروف ترین اوقات مصروف ترین اوقات ہوں گے اور لوڈ ٹیسٹ کی مدت مقرر کریں گے۔

4.1 نیا نمونہ - NRQL

اب جب کہ آپ اپنے مصروف ترین دنوں کو جانتے ہیں، یہ مرحلہ اسے آپ کے مصروف ترین اوقات تک محدود کر دیتا ہے۔ مندرجہ ذیل استفسار NRQL کے TIMESERIES فنکشن کا استعمال کرتا ہے تاکہ چوٹی کے دنوں میں ٹریفک کو گھنٹہ کے وقفوں میں شامل کیا جا سکے، تاکہ آپ دیکھ سکیں کہ دن کے دوران بوجھ کیسے بڑھتا اور کم ہوتا ہے۔

پہلی استفسار سرور سائیڈ ٹرانزیکشنل ڈیٹا پر کام کرتی ہے، جب کہ دوسری براؤزر انٹرایکشن ایونٹ کا استعمال کرتی ہے، جو کہ سنگل پیج ایپلیکیشنز کے لیے اہم ہے جہاں زیادہ تر صارف کی سرگرمی پورے صفحے کے بوجھ کے بغیر ہوتی ہے۔

-- Step 2a: Peak Hour — server-side transaction volume
SELECT
  count(*) AS requests_per_hour,
  rate(count(*), 1 minute) AS avg_rpm_within_hour,
  average(duration) AS avg_response_sec,
  percentile(duration, 50, 95, 99) AS latency_pct
FROM Transaction
WHERE
  appName="your-app-name"
  AND transactionType="Web"
TIMESERIES 1 hour
SINCE '2025-11-28 00:00:00'
UNTIL '2025-11-28 23:59:59'

-- Step 2b: For SPA applications — BrowserInteraction is the key event type
 
SELECT
  count(*) AS interactions,
  uniqueCount(session) AS concurrent_sessions,
  average(duration) AS avg_interaction_ms,
  filter(count(*), WHERE category = 'Route change') AS navigations
FROM BrowserInteraction
WHERE appName="your-app-name"
TIMESERIES 1 hour
SINCE '2025-11-28 00:00:00'
UNTIL '2025-11-28 23:59:59'

4.2 Dynatrace - USQL

Dynatrace مساوی بالٹی سیشن چوٹی کے دنوں کے دوران فی گھنٹہ کے سلاٹ میں سیشن کرتا ہے اور صارف کی کل سرگرمی کے مطابق انہیں آرڈر کرتا ہے۔ مصروف ترین اوقات چوٹی کے اوقات ہیں۔

چونکہ USQL سیشن کی سطح پر کام کرتا ہے، یہ سیشن کی گنتی اور P95 فی گھنٹہ سیشن کا دورانیہ بھی فراہم کرتا ہے، جو اس بات کو یقینی بنانے میں مدد کرتا ہے کہ حجم کے لحاظ سے مصروف ترین وقت بھی وہی ہے جو صارف کی مصروفیت کے لحاظ سے ضروری ہے۔

// Step 2 --- Dynatrace USQL: Peak Hour from user sessions

SELECT
  DATETIME(startTime, 'HH:00', 'yyyy-MM-dd HH:mm') AS peak_hour,
  COUNT(*) AS session_count,
  SUM(userActionCount) AS total_actions,
  AVG(duration) AS avg_session_ms,
  PERCENTILE(duration, 95) AS p95_session_ms
FROM usersession
WHERE
  startTime > '2025-11-28T00:00:00'
  AND startTime < '2025-11-28T23:59:59'
  AND applicationType="BROWSER"
GROUP BY DATETIME(startTime, 'HH:00', 'yyyy-MM-dd HH:mm')
ORDER BY total_actions DESC

5. مرحلہ 3 - چوٹی منٹ کا تجزیہ

بنیادی ڈھانچے کو چوٹی منٹوں کو ہینڈل کرنا چاہئے، جو کہ ایک بدترین کیس 60 سیکنڈ کی ونڈو ہے۔ یہ لوڈ ٹیسٹ RPS ہدف فراہم کرتا ہے۔

سرکاری: ہدف RPS = زیادہ سے زیادہ وقت کی درخواستیں / 60

5.1 نیا نمونہ - NRQL

چونکہ نیو ریلیک میں 60 سیکنڈ کی بالٹی کی ڈیفالٹ خصوصیت نہیں ہے، اس لیے ہم چوٹی کے اوقات میں TIMESERIES 1 منٹ کا استفسار کرتے ہیں یہ اس گھنٹے کے ہر ایک منٹ کے لیے درخواستوں کی تعداد واپس کر دے گا، جس میں سب سے زیادہ چوٹی کا وقت ہوگا۔ اس نمبر کو 60 سے تقسیم کرنے سے لوڈ ٹیسٹنگ کے لیے بنیادی RPS ہدف ملتا ہے۔

-- Step 3a: Drill to Peak Minute within the peak hour
-- Replace 11:00:00 / 11:59:59 with your actual peak hour

SELECT
  count(*) AS requests_per_minute,
  uniqueCount(session) AS active_sessions_per_min,
  rate(count(*), 1 second) AS rps,
  percentile(duration, 95) AS p95_latency
FROM Transaction
WHERE
  appName="your-app-name"
  AND transactionType="Web"
TIMESERIES 1 minute
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'

-- Step 3b: Get the max 1-minute request count
-- peak_rps is your load test baseline target (before growth multiplier)

SELECT
  max(count(*)) AS peak_minute_requests,
  max(rate(count(*), 1 second)) AS peak_rps
FROM Transaction
WHERE
  appName="your-app-name"
  AND transactionType="Web"
TIMESERIES 1 minute
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'

فیز 3 کے کلیدی نتائج: اب آپ کے پاس چوٹی کا RPS گول ہے۔ مثال: زیادہ سے زیادہ فی منٹ = 4,800 درخواستیں، اس لیے بیس لائن = 80 RPS۔ 1.3x نمو اور 1.1x حفاظتی بفر کے ساتھ: 80 × 1.3 × 1.1 = 114 RPS کی حد لوڈ ٹیسٹنگ کے لیے۔

5.2 Dynatrace - USQL

Dynatrace چوٹی کے اوقات کے دوران سیشنز کو منٹ کی بالٹیوں میں گروپ کرکے اور انہیں حجم کے لحاظ سے ترتیب دے کر ایک ہی نتیجہ تک پہنچتا ہے۔ مصروف ترین اوقات سب سے اوپر دکھائے جاتے ہیں۔ USQL سیشن کی سطح پر کام کرتا ہے، اس لیے شمار اس منٹ میں شروع ہونے والے سیشنز کی عکاسی کرتا ہے، جو پھر اسی طرح RPS اہداف میں تبدیل ہو جاتے ہیں۔

-- Step 3a: Peak Minute: session counts per minute within peak hour
-- Buckets sessions into 1-minute slots --- highest bucket = peak minute

SELECT
  DATETIME(startTime, 'HH:mm', 'yyyy-MM-dd HH:mm') AS peak_minute,
  COUNT(*) AS session_count,
  SUM(userActionCount) AS total_actions,
  AVG(duration) AS avg_session_ms,
  PERCENTILE(duration, 95) AS p95_session_ms
FROM usersession
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"
GROUP BY DATETIME(startTime, 'HH:mm', 'yyyy-MM-dd HH:mm')
ORDER BY session_count DESC

-- The top row = your peak minute.
-- session_count is not request count --- see Step 3b below for RPS derivation.

-- Step 3b: Derive RPS from concurrent users in peak minute
--
-- USQL works at session level, not request level.
-- RPS is derived using the concurrent user formula applied per minute:
--   Concurrent Users = (sessions_in_minute x avg_duration_sec) / 60
--   RPS estimate = concurrent_users / avg_response_time_sec
--
-- For accurate request-level RPS use Dynatrace Service metrics in the UI:
--   Observe > Services > [your service] > Metrics > Request count, 1m resolution

SELECT
  DATETIME(startTime, 'HH:mm', 'yyyy-MM-dd HH:mm') AS peak_minute,
  COUNT(*) AS session_count,
  AVG(duration) / 1000 AS avg_duration_sec,
  (COUNT(*) * (AVG(duration) / 1000)) / 60 AS concurrent_users_in_minute,
  COUNT(*) / 60 AS sessions_per_second
FROM usersession
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"
GROUP BY DATETIME(startTime, 'HH:mm', 'yyyy-MM-dd HH:mm')
ORDER BY session_count DESC
LIMIT 1

-- LIMIT 1 returns only the peak minute row.
-- concurrent_users_in_minute is your VU count for that 60-second window.
-- sessions_per_second is a session arrival rate (not HTTP RPS).

6. مرحلہ 4 - عمارت کا منظر نامہ مکس

چوٹی کے اوقات کے دوران اصل URL اور لین دین کی تقسیم سے استفسار کریں۔ یہ اندازوں کے بجائے ثبوت پر مبنی منظر نامہ کا وزن پیدا کرتا ہے۔

6.1 نیا نمونہ – NRQL

یہ مرحلہ استفسار کرتا ہے کہ صارفین نے زیادہ سے زیادہ اوقات کے دوران اصل میں کیا کیا، لہذا منظر نامے کا وزن اندازہ لگانے کے بجائے اصل ٹریفک سے آتا ہے۔

نیو ریلک اس پر تین زاویے پیش کرتا ہے۔ پہلی استفسار لین دین کو حجم کے لحاظ سے درجہ بندی کرتا ہے، جس سے ظاہر ہوتا ہے کہ سرور کی طرف سے کون سے آپریشنز غالب ہیں۔ دوسرا ان URLs کی درجہ بندی ہے جنہیں صارف نے اصل میں ملاحظہ کیا، یعنی براؤزر سائیڈ ویو۔ تیسرا، یہ دکھانے کے لیے فنل چلائیں کہ سیشن کس طرح اہم مراحل سے گزرے اور وہ کہاں رکے۔ ایک ساتھ، وہ آپ کو یہ جاننے میں مدد کرتے ہیں کہ آپ کی لوڈ ٹیسٹنگ میں کن منظرناموں کو شامل کرنا ہے اور ہر منظر نامے کو کتنا وزن دینا ہے۔

-- Step 4a: Scenario mix --- APM transaction distribution

SELECT
  count(*) AS hit_count,
  percentage(count(*), WHERE name IS NOT NULL) AS pct_of_total,
  average(duration) AS avg_ms,
  percentile(duration, 95) AS p95_ms
FROM Transaction
WHERE
  appName="your-app-name"
  AND transactionType="Web"
FACET name
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'
LIMIT 20
ORDER BY hit_count DESC

-- Step 4b: Browser perspective --- top routes visited by users

SELECT
  count(*) AS views,
  uniqueCount(session) AS unique_sessions,
  average(duration) AS avg_load_ms
FROM PageView
WHERE
  appName="your-app-name"
  AND pageUrl NOT LIKE '%/static/%'
  AND pageUrl NOT LIKE '%/api/%'
FACET pageUrl
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'
LIMIT 20

-- Note: ORDER BY views DESC omitted --- uniqueCount(session) prevents it.
-- Click the views column header in Query Builder to sort descending.

-- Step 4c: Funnel analysis --- user journey drop-off at each stage

SELECT
  funnel(session,
    WHERE pageUrl LIKE '%/' AS 'Homepage',
    WHERE pageUrl LIKE '%/category/%' AS 'Category Browse',
    WHERE pageUrl LIKE '%/search%' AS 'Search',
    WHERE pageUrl LIKE '%/product/%' AS 'Product Detail',
    WHERE pageUrl LIKE '%/cart%' AS 'Cart',
    WHERE pageUrl LIKE '%/checkout%' AS 'Checkout',
    WHERE pageUrl LIKE '%/confirmation%' AS 'Order Confirm'
  ) AS checkout_funnel
FROM PageView
WHERE appName="your-app-name"
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'

6.2 Dynatrace - USQL

Dynatrace ورژن صفحہ یو آر ایل کے بجائے صارف کے اعمال سے اس کا منظر نامہ ملاتا ہے۔ چوٹی کے اوقات میں سرگرمیاں کام کے نام کے لحاظ سے گروپ کی جاتی ہیں اور تعدد کے لحاظ سے درجہ بندی کی جاتی ہیں، لہذا سب سے زیادہ عام صارف کے کام سب سے اوپر ظاہر ہوتے ہیں۔ یہ تعدد منظر نامے کا وزن بن جاتا ہے، جیسا کہ نیو ریلیک ٹرانزیکشن اور یو آر ایل کا شمار ہوتا ہے۔

// Top user action names during peak hour --- Dynatrace USQL

SELECT
  userActionName,
  COUNT(*) AS action_count,
  AVG(duration) AS avg_duration_ms,
  PERCENTILE(duration, 95) AS p95_ms
FROM useraction
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"
GROUP BY userActionName
ORDER BY action_count DESC
LIMIT 20

6.3 نمونہ منظر نامہ مکس آؤٹ پٹ

جب مندرجہ بالا سوالات کو یکجا کیا جاتا ہے، مکمل منظر نامے کا مجموعہ اس طرح ہوتا ہے: ہر قطار صارف کا بہاؤ ہے جس میں کل ٹریفک کا حصہ ہوتا ہے، جس کے نتیجے میں RPS ہدف، اوسط، اور P95 جوابی وقت ہوتا ہے۔ یہ فیصد لوڈ ٹیسٹ میں منظر نامے کا وزن بن جاتے ہیں، اور RPS کالم آپ کو بتاتا ہے کہ ہر فیصد کے ذریعے کتنا بوجھ منتقل کرنا ہے۔

منظرنامہ/صارف کا بہاؤ	ہٹ کی تعداد	% لوڈ	ہدف آر پی ایس	اوسط (ملی سیکنڈز)	P95 SLAs
ہوم پیج → زمرہ جات کو براؤز کریں۔	42,840	28%	23.0	320	<800ms
تلاش کریں → مصنوعات کی فہرست	35,200	23%	18.9	450	< 1,200 ms
پروڈکٹ کی تفصیلات کا صفحہ (PDP)	29,600	19%	15.6	280	<700ms
ٹوکری میں شامل کریں۔	18,400	12%	9.8	190	<500ms
خریداری کی ٹوکری → ادائیگی شروع کریں۔	12,800	8%	6.6	520	< 1,500 ms
ادائیگی → ادائیگی	8,760	6%	4.9	1,200	<3,500 ms
آرڈر کی تصدیق	4,980	4%	3.3	240	<600ms

7. مرحلہ 5 – ہم وقت استعمال کرنے والے

کنکرنٹ یوزرز ایک مخصوص ٹائم ونڈو کے اندر سسٹم پر فعال طور پر موجود صارفین کی تعداد ہیں۔ سیشن لیول ڈیٹا کے ساتھ کام کرتے وقت، نیو ریلک براؤزر یا ڈائنٹریس RUM کا سب سے مستند ذریعہ، درست فارمولا یہ ہے:

کنکرنٹ صارفین = (گھنٹہ وار سیشن × اوسط سیشن کا دورانیہ (سیکنڈ)) / 3600

یہ فارمولہ کنکرنسی کی تعریف سے اخذ کیا گیا ہے۔ اگر کوئی سیشن D سیکنڈ تک جاری رہتا ہے اور فی گھنٹہ S سیشنز آرہے ہیں تو کسی بھی وقت اوور لیپنگ سیشنز کی متوقع تعداد (S × D) / 3600 ہے۔ تقسیم کار 3600 فی گھنٹہ سیشنز کی تعداد کو فی سیکنڈ آمد کی شرح میں تبدیل کرتا ہے۔

ہاں: 4,280 چوٹی گھنٹے کے سیشن × اوسط دورانیہ 444 سیکنڈ / 3600 = 529 ہم وقت صارفین کسی بھی لمحے ۔ گروتھ فیکٹر ایپلی کیشن: 529 × 1.3 = 688 SUVs.

RPS x اوسط رسپانس ٹائم کیوں نہیں؟ فارمولہ RPS اوپر دیا گیا سیشن لیول کا فارمولا لوڈ ٹیسٹنگ میں ورچوئل صارفین کو سائز دینے کے لیے بہتر ہے۔ اس کی وجہ یہ ہے کہ VUs سفر پر نیویگیٹ کرنے والے پورے صارف کی نمائندگی کرتے ہیں، انفرادی HTTP درخواستوں کی نہیں۔

بالآخر، ہم انفراسٹرکچر اسکیلنگ کے لیے لین دین کی ہم آہنگی اور VU شمار کے لیے سیشن کنکرنسی دونوں استعمال کرنے کی تجویز کرتے ہیں۔

7.1 نیا نمونہ - NRQL

یہ مرحلہ سیشن ڈیٹا کو ورچوئل صارفین کی تعداد میں تبدیل کرتا ہے جن کی اصل میں لوڈ ٹیسٹنگ انجن کو ضرورت ہوتی ہے۔

New Relic دو آراء پیش کرتا ہے: پہلی استفسار فی سفر کے نتائج پر ایک ہم آہنگی کے فارمولے کا اطلاق کرتی ہے، جس سے ہمیں یہ تعین کرنے کی اجازت ملتی ہے کہ ہر منظر نامے کے لیے کتنے VUs کی ضرورت ہے (تبدیل شدہ، کارٹ کو چھوڑ دیا گیا، باؤنس کیا گیا، وغیرہ)۔ دوسرا ایک کل پیدا کرنے کے لیے چوٹی کے اوقات میں فارمولہ چلاتا ہے۔ یہ VU پول کی حدود کے لیے ایک مفید سنٹی چیک ہے جس کا آپ اگلے مرحلے میں حساب لگاتے ہیں۔

-- Step 5a: Concurrent Users = (Hourly Sessions x Avg Session Duration in sec) / 3600
-- FACET by journey_outcome (NOT by session --- that would give 1 row per session)
-- uniqueCount(session) counts distinct sessions within each outcome bucket

SELECT
  uniqueCount(session) AS hourly_sessions,
  average(sessionDuration) AS avg_session_duration_sec,
  (uniqueCount(session) * average(sessionDuration)) / 3600 AS concurrent_users
FROM PageView
WHERE appName="your-app-name"
FACET
  CASE
    WHEN latest(pageUrl) LIKE '%/confirmation%' THEN 'converted'
    WHEN latest(pageUrl) LIKE '%/payment%' THEN 'payment_drop'
    WHEN latest(pageUrl) LIKE '%/checkout%' THEN 'checkout_drop'
    WHEN latest(pageUrl) LIKE '%/cart%' THEN 'cart_abandon'
    WHEN latest(pageUrl) LIKE '%/product/%' THEN 'browse_exit'
    ELSE 'early_exit'
  END AS journey_outcome
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'

-- Step 5b: Total concurrent users across entire peak hour
-- Formula: (total sessions x avg session duration seconds) / 3600

SELECT
  uniqueCount(session) AS hourly_sessions,
  average(sessionDuration) AS avg_session_duration_sec,
  (uniqueCount(session) * average(sessionDuration)) / 3600 AS concurrent_users_formula,
  uniqueCount(session) / 60 AS sessions_per_minute
FROM PageView
WHERE appName="your-app-name"
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'

-- Example output:
-- hourly_sessions = 4,280
-- avg_session_duration_sec = 444
-- concurrent_users_formula = (4280 x 444) / 3600 = 528.2 -> round to 529
-- Apply 1.3x growth: 529 x 1.3 = 688 VUs

7.2 Dynatrace - USQL

Dynatrace ورژن ایک ہی فارمولے کا اطلاق کرتا ہے، لیکن نوٹ کرنے کے لیے ایک فرق ہے۔ دورانیہ کی فیلڈ ملی سیکنڈ میں ہے، لہذا حساب سے پہلے سیکنڈوں کی تعداد حاصل کرنے کے لیے 1000 سے تقسیم کریں۔ استفسار چوٹی کے اوقات کے دوران ہم وقت صارفین کی تعداد لوٹاتا ہے، جو براہ راست VU پول سائز میں ترجمہ کرتا ہے۔

// Concurrent Users = (Hourly Sessions x Avg Session Duration in seconds) / 3600
// Dynatrace duration field is already in milliseconds --- divide by 1000

SELECT
  COUNT(*) AS hourly_sessions,
  AVG(duration) / 1000 AS avg_session_duration_sec,
  (COUNT(*) * AVG(duration) / 1000) / 3600 AS concurrent_users
FROM usersession
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"

-- Per outcome segment (maps to load test scenario VU split):

SELECT
  COUNT(*) AS hourly_sessions,
  AVG(duration) / 1000 AS avg_session_duration_sec,
  (COUNT(*) * AVG(duration) / 1000) / 3600 AS concurrent_users
FROM usersession
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"
GROUP BY
  CASE WHEN userActions.name[userActionCount - 1] LIKE '%confirmation%' THEN 'converted'
       WHEN userActions.name[userActionCount - 1] LIKE '%cart%' THEN 'cart_abandon'
       ELSE 'other' END

8. مرحلہ 6 - فعال سیشنز اور کل VU پول

چوٹی کے اوقات کے دوران انفرادی سیشنز کی تعداد اس مدت کے دوران مشاہدہ کیے گئے سیشنز کی کل آبادی کی نمائندگی کرتی ہے۔ اسے ورچوئل یوزر پول کے لیے مختص بالائی حد کے طور پر استعمال کیا جا سکتا ہے، اور مرحلہ 5 میں ہم آہنگی کا حساب کتاب ان صارفین کی تعداد کا تخمینہ لگاتا ہے جو ایک ہی وقت میں فعال ہیں۔

اپنے لوڈ ٹیسٹ کو ترتیب دیتے وقت دونوں اقدار کا استعمال کریں۔

• ایک ساتھ استعمال کرنے والوں کے پانچ درجے: ایک ساتھ فعال VUs کی تخمینی تعداد۔

• 6 منفرد فعال سیشن: چوٹی کے اوقات کے کام کے بوجھ میں سیشن کی کل آبادی۔

8.1 نیا نمونہ – NRQL

یہ قدم VU پول پر سخت حدیں متعین کرتا ہے، یعنی چوٹی کے اوقات میں فعال انفرادی سیشنز کی کل تعداد۔ New Relic اسے UniqueCount (سیشن) کے ذریعے فراہم کرتا ہے اور آپ کے ٹیسٹ سیٹ اپ کو مطلع کرنے کے لیے مزید مکمل سیشن پروفائل فراہم کرتا ہے۔

پہلا سوال فعال سیشنز کی خام تعداد لوٹاتا ہے۔ دوسرے لوگ آبادی کو نئے اور واپس آنے والے صارفین اور سیشن کی گہرائی میں تقسیم کرکے لوڈ ٹیسٹنگ کے منظرناموں میں حقیقت پسندانہ سوچ کے اوقات اور نیویگیشن پیٹرن کو تشکیل دینے میں مدد کرتے ہیں۔

-- Step 6a: Full session picture for the peak hour
-- total_active_sessions is your VU pool ceiling
-- Note: sessionDuration and sessionPageViews are Browser agent attributes.
-- They require New Relic Browser agent to be instrumented on your app.

SELECT
  uniqueCount(session) AS distinct_sessions_in_peak_hour,
  average(sessionDuration) AS avg_session_duration_sec,
  percentile(sessionDuration, 50, 90) AS session_duration_pct,
  average(sessionPageViews) AS avg_pages_per_session,
  filter(uniqueCount(session), WHERE sessionPageViews = 1) AS bounce_sessions,
  filter(uniqueCount(session), WHERE sessionPageViews >= 5) AS engaged_sessions
FROM PageView
WHERE appName="your-app-name"
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'

-- Step 6b: New vs returning --- affects cache warm state in load test.
-- nr.customAttribute.isNewUser is a CUSTOM attribute --- your team must set
-- this via the Browser API: newrelic.setCustomAttribute("isNewUser", true/false)
-- If not instrumented, use nr.session (first visit = new) or omit this query.

SELECT
  uniqueCount(session) AS session_count,
  average(duration) AS avg_page_load_ms
FROM PageView
WHERE appName="your-app-name"
FACET nr.customAttribute.isNewUser
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'

-- Step 6c: Sessions active each minute across the peak hour.
-- Use this to see the shape of traffic within the hour.
-- The max bar = your peak concurrent session minute.

SELECT
  uniqueCount(session) AS active_sessions
FROM PageView
WHERE appName="your-app-name"
TIMESERIES 1 minute
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'

8.2 Dynatrace - USQL

Dynatrace حسب ضرورت انسٹرومینٹیشن کی ضرورت کے بغیر، ڈیفالٹ کے طور پر یوزر سیشن ہستی میں تمام سیشن پراپرٹیز کو اسٹور کرتا ہے۔ نیچے دی گئی استفسار وہی سیشن پروفائل بناتی ہے جو اوپر کی گئی NRQL استفسار ہے، نیز کچھ اضافی فیلڈز جو Dynatrace بطور ڈیفالٹ ظاہر کرتی ہے۔

// Step 6a --- Dynatrace USQL: Full session profile for peak hour
// total_sessions is your VU pool ceiling

SELECT
  COUNT(*) AS total_sessions,
  AVG(duration) / 1000 AS avg_duration_sec,
  AVG(userActionCount) AS avg_actions_per_session,
  (COUNT(*) * (AVG(duration) / 1000)) / 3600 AS concurrent_users,
  (COUNT(*) * (AVG(duration) / 1000)) / 3600 * 1.3 AS vus_1_3x,
  (COUNT(*) * (AVG(duration) / 1000)) / 3600 * 1.3 * 1.1 AS vus_with_buffer,
  SUM(CASE WHEN userActionCount = 1 THEN 1 ELSE 0 END) AS bounce_sessions,
  SUM(CASE WHEN userActionCount >= 5 THEN 1 ELSE 0 END) AS engaged_sessions
FROM usersession
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"

// Step 6b --- New vs returning users (built-in field --- no custom instrumentation needed)
// newUser is a native boolean field on the usersession entity

SELECT
  SUM(CASE WHEN newUser = TRUE THEN 1 ELSE 0 END) AS new_users,
  SUM(CASE WHEN newUser = FALSE THEN 1 ELSE 0 END) AS returning_users,
  COUNT(*) AS total_sessions,
  AVG(duration) / 1000 AS avg_duration_sec,
  AVG(userActionCount) AS avg_actions
FROM usersession
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"

// Step 6c --- Sessions per minute within peak hour
// ORDER BY minute_slot ASC keeps time order for the sparkline chart

SELECT
  DATETIME(startTime, 'HH:mm', 'yyyy-MM-dd HH:mm') AS minute_slot,
  COUNT(*) AS active_sessions
FROM usersession
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"
GROUP BY DATETIME(startTime, 'HH:mm', 'yyyy-MM-dd HH:mm')
ORDER BY minute_slot ASC

// Step 6d --- Session depth: how many pages/actions per session
// Informs think time distribution in load test scripts

SELECT
  CASE
    WHEN userActionCount = 1 THEN "1 action (bounce)"
    WHEN userActionCount BETWEEN 2 AND 3 THEN "2-3 actions"
    WHEN userActionCount BETWEEN 4 AND 6 THEN "4-6 actions"
    WHEN userActionCount >= 7 THEN "7+ actions (engaged)"
  END AS depth_bucket,
  COUNT(*) AS session_count
FROM usersession
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"
GROUP BY depth_bucket
ORDER BY session_count DESC

9. حتمی کام کا بوجھ ماڈل

تمام چھ مراحل کو انجام دینے کے بعد، آپ کے کام کے بوجھ کے ماڈل میں تمام نمبروں کو تخمینوں کے بجائے براہ راست استفسار کے نتائج پر ٹریس کیا جا سکتا ہے۔

9.1 خلاصہ پیرامیٹرز

یہ جدول چھ پیدا شدہ مراحل سے تمام اعداد کو کام کے بوجھ کے ایک ماڈل میں یکجا کرتا ہے۔ بایاں کالم پچھلے سال کے اعلی سے اخذ کردہ اقدار کو ظاہر کرتا ہے، گروتھ ایڈجسٹ کالم آپ کے منتخب کردہ ضرب کو لاگو کرتا ہے، اور اصل سوال کا کالم ہر نمبر کے عین مطابق قدم کی طرف اشارہ کرتا ہے، جس سے ماڈل کا جائزہ لینے والے کسی بھی شخص کو حقیقی ٹیلی میٹری کا پتہ لگانے کی اجازت ملتی ہے۔

پیرامیٹر	مثال: قدر (پچھلے سال کی بلندی)	مثال: قدر (1.3x اضافہ)	ذریعہ استفسار
چوٹی کا موسم	28 نومبر 2025	(وہی حوالہ)	مرحلہ 1 NRQL/USQL
چوٹی کا وقت	11:00 - 12:00	(وہی حوالہ)	مرحلہ 2 NRQL/USQL
چوٹی منٹ آر پی ایس	82 آر پی ایس	107 آر پی ایس	مرحلہ 3 NRQL/USQL
کل ایکٹو سیشنز (VU پول)	4,280	5,564	مرحلہ 6 NRQL/USQL
سرفہرست منظرنامے۔	7	7	مرحلہ 4 NRQL/USQL
ٹیسٹ کی مدت	60 منٹ	60 منٹ	مرحلہ 2 NRQL/USQL

9.2 منظرنامہ VU مختص

یہ جدول انفرادی منظرناموں میں کل VU پول کی درجہ بندی کرنے کے لیے وزن کی چار سطحوں کا استعمال کرتا ہے۔ ہر قطار ایک منظر نامے کے لیے لوڈ فیصد، ہدف RPS، کنکرنٹ VUs کی تعداد، اور P95 SLA فراہم کرتی ہے، جو آپ کو اس منظر نامے کو براہ راست لوڈ ٹیسٹنگ انجن میں ترتیب دینے کے لیے درکار ہے۔

سکرپٹ	مثال: لوڈ %	مثال: ہدف RPS	مثال: کنکرنٹ VUs	مثال: P95 SLA
ہوم پیج → براؤز کریں۔	28%	23.0	1,558	<800ms
تلاش کریں → PLP	23%	18.9	1,280	< 1,200 ms
مصنوعات کی تفصیلات (PDP)	19%	15.6	1,057	<700ms
ٹوکری میں شامل کریں۔	12%	9.8	668	<500ms
خریداری کی ٹوکری → ادائیگی	8%	6.6	445	< 1,500 ms
ادائیگی → ادائیگی	6%	4.9	334	<3,500 ms
آرڈر کی تصدیق	4%	3.3	222	<600ms

10. صارف کا سفر - لینڈنگ پیج سے ایگزٹ پیج تک

صارف کے پورے سفر کو سمجھنا، پہلے صفحے سے لے کر آخری صفحہ تک جس پر کوئی وزیٹر آتا ہے، وہ سب سے طاقتور بصیرت مشاہداتی ڈیٹا ہے جو ٹیسٹنگ کو لوڈ کرنے کے لیے فراہم کر سکتا ہے۔

خلاصہ "لین دین" کی ماڈلنگ کرنے کے بجائے، یہ سیکشن دکھاتا ہے کہ ہر سیشن (ان پٹ کے ذرائع، نیویگیشن کے اقدامات، ڈراپ آف پوائنٹس، اور حتمی نتائج) کو تبدیل کرنے والے چار سوالوں کی زنجیر کا استعمال کرتے ہوئے جو انفرادی سیشن کے ریکارڈ اور مجموعی راستے کی گنتی دونوں کو پیدا کرتا ہے، کے ذریعے اٹھائے گئے پورے راستے کو کیسے دوبارہ تشکیل دیا جائے۔

FUNNEL() استفسار (مرحلہ 4) اور فی سیشن FACET سیشن استفسار مختلف مقاصد کو پورا کرتا ہے۔

1. FUNNEL() ان سیشنز کی تعداد کو شمار کرتا ہے جنہوں نے ہر قدم پر دورہ کیا، لیکن یہ نہیں معلوم کہ سیشن کہاں ختم ہوا۔

2. FACET سیشن استفسار آپ کو ہر سیشن کے آغاز اور اختتامی صفحات بتاتا ہے، لیکن شمار میٹرکس کے بجائے فی سیشن ایک قطار واپس کرتا ہے۔ ہر داخلی + خارجی امتزاج کے اشتراک کرنے والے سیشنز کی تعداد شمار کرنے کے لیے ایک علیحدہ مجموعی استفسار (7B) درکار ہے۔

10.1 صارف کے سفر کا نقشہ

ای کامرس کا پورا سفر پانچ انفرادی مراحل میں پھیلے ہوئے نو مراحل پر مشتمل ہے۔ ہر مرحلے کا اپنا بوجھ پروفائل، ردعمل کے وقت کی خصوصیات، اور گھومنے پھرنے کے خطرات ہوتے ہیں جنہیں لوڈ ٹیسٹنگ میں آزادانہ طور پر ماڈل بنایا جانا چاہیے۔

قدم	قدم	سیشن (زیادہ سے زیادہ وقت)	منتھل خطرہ	لوڈ ٹیسٹ کی ترجیح
عنصر	درخواست کا ذریعہ → ہوم پیج	28,410 لوگ داخل ہوئے۔	لینڈنگ پر 13% اچھال	درمیانی
تلاش کریں	براؤز/تلاش → PDP	24,716 → 17,330	شاپنگ کارٹ سے پہلے 30% چھوٹ	اعلی
مرضی	کارٹ میں شامل کریں → ریویو کارٹ	13,637 → 8,580	37% خریداری کی ٹوکری کو چھوڑ دیتے ہیں۔	تنقیدی
تبدیلی	ادائیگی → ادائیگی → جائزہ	5,054 → 4,088	7% ادائیگی میں ناکامی۔	تنقیدی
تکمیل	آرڈر کی تصدیق → آرڈر کرنے کے بعد	3,706 لوگوں نے تصدیق کی۔	کم سیشن ختم ہوتا ہے۔	کم

10.2 چار سوالات کی زنجیریں۔

مکمل تصویر حاصل کرنے کے لیے چار سوالات درکار ہیں: ہر ایک مختلف تجزیہ کا مقصد پورا کرتا ہے اور کام کے بوجھ کے ماڈل کا ایک مختلف حصہ فراہم کرتا ہے۔

سوال	نام	جو واپس کیا جاتا ہے۔	استعمال کریں
7A	سیشن کے لیے مخصوص ریکارڈنگ	فی سیشن ایک قطار: صفحہ شروع، اختتامی صفحہ، دورانیہ، ملاحظہ کیے گئے صفحات، تبدیل شدہ جھنڈے	انفرادی سیشن تجزیہ، آؤٹ لیئر کا پتہ لگانا، نمونہ ڈیبگنگ
7B	داخلہ × باہر نکلیں میٹرکس	ایک قطار فی اندراج + باہر نکلنے کا مجموعہ: ہر راستے کے جوڑے کے لیے سیشنز کی تعداد - ہیٹ میپ۔	پاتھ فریکوئنسی تجزیہ کے ذریعے چرن کے سب سے بڑے امتزاج کی شناخت کریں۔
7C	نتیجہ بالٹی کے ساتھ فی سیشن	1 قطار فی سیشن CASE کے لحاظ سے ترتیب کردہ نتائج کے ساتھ: تبدیل شدہ، cart_abandon، checkout_drop، Payment_drop، browser_exit، early_exit	جمع کرنے سے پہلے طبقہ کی سطح کا تجزیہ
7D	کام کے بوجھ کے ماڈل سے نتائج کی تعداد	1 قطار فی نتیجہ بالٹی: شمار، کل کا %، اوسط عمر، اوسط صفحہ - براہ راست VU وزن فراہم کرتا ہے	کام کا بوجھ ماڈل منظر نامہ وزن - سب سے اہم سوالات

10.3 استفسار 7A - سیشن کے لیے مخصوص ریکارڈز

یہ استفسار فی سیشن ایک قطار لوٹاتا ہے۔ یہ آپ کو بخوبی بتاتا ہے کہ ہر انفرادی سیشن کہاں آیا اور کہاں چلا گیا، یہ کتنی دیر تک چلا، اس نے کتنے صفحات کا دورہ کیا، اور آیا یہ تبدیل ہوا۔ آپ ہیٹ میپ سیل کی گنتی خود نہیں بنا سکتے کیونکہ اس کے لیے استفسار 7B کی ضرورت ہے۔

-- Query 7A: One row per session
-- Use for: individual session analysis, debugging, outlier detection
-- Cannot produce heatmap counts --- use Query 7B for that

SELECT
  session,
  earliest(pageUrl) AS entry_page,
  latest(pageUrl) AS exit_page,
  count(pageUrl) AS pages_visited,
  max(timestamp) - min(timestamp) AS session_duration_ms,
  filter(count(*), WHERE pageUrl LIKE '%/confirmation%') AS converted
FROM PageView
WHERE appName="your-app-name"
FACET session
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'
LIMIT 1000

-- ORDER BY not supported with multiple aggregations on FACET session.
-- Sort by session_duration_ms column in Query Builder UI instead.

استفسار 7A کے لیے نمونہ آؤٹ پٹ:

سیشن	آئٹم_صفحہ	exit_page	صفحہ	duration_ms	تبدیل
sess_a3f8c2	/	/چیک کریں۔	8	862,000	1 (مثال)
sess_b7d1e9	/زمرہ/الیکٹرانکس	/گاڑی	5	545,000	0 (نہیں)
sess_c2a4f1	/	/گاڑی	4	348,000	0 (نہیں)
sess_d9e3b7	/search?q=Shoes	/چیک کریں۔	6	693,000	1 (مثال)
sess_e1f5a2	/پروڈکٹ/جیکٹ	/پروڈکٹ/جیکٹ	1	45,000	0 (نہیں)

میمو: کہ duration_ms کالموں کا حساب درج ذیل ہے: max(timestamp) - min(timestamp). سیشن کے پہلے اور آخری صفحہ کے ملاحظات کے درمیان وال کلاک کا وقت۔ جوابی وقت نہیں۔ sess_a3f8c2 اوپر = 862,000ms کے لیے کل سیشن کا وقت تقریباً 14 منٹ اور 22 سیکنڈ ہے۔

10.4 سوال 7B - اندراج × باہر نکلیں میٹرکس (ہیٹ میپ)

یہ ایک سوال ہے جو ہیٹ میپ سیلز کی تعداد پیدا کرتا ہے۔ دوہری FACET استعمال کرتا ہے۔ earliest(pageUrl) اور latest(pageUrl) سیشنز کو آپ کے درج کردہ صفحہ اور جانے سے پہلے آخری صفحہ کے لحاظ سے گروپ کیا جاتا ہے۔ شمار

-- Query 7B: Heatmap cell counts
-- Use for: path frequency matrix, identifying biggest drop-off combinations
-- THIS is what produces the cell values

SELECT
  count(*) AS session_count
FROM PageView
WHERE appName="your-app-name"
FACET
  earliest(pageUrl) AS entry_page,
  latest(pageUrl) AS exit_page
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'
LIMIT 100
ORDER BY session_count DESC

ہر inlet + outlet کے امتزاج کے لیے سیشنز کی تعداد فراہم کرتا ہے۔

استفسار 7B کے لیے نمونہ آؤٹ پٹ:	آئٹم_صفحہ	exit_page	سیشن_کاؤنٹ
تجزیہ	/	/گاڑی	1,840
سب سے بڑی کمی - 1,840 سیشن ہوم پیج سے شاپنگ کارٹ تک پہنچے لیکن آگے نہیں گئے۔	/زمرہ	/گاڑی	2,100
خریداری کی ٹوکری میں پھنسا زمرہ براؤزر - سب سے بڑا واحد ترک کرنے والا گروپ	/مصنوعات	/چیک کریں۔	1,620
ڈیپ لنک خریدار - براہ راست PDP میں داخل ہو کر مکمل خریداری۔ اعلیٰ ترین ارادے والے حصے۔	/	/معائنہ	820
ادائیگی پہنچ گئی لیکن ادائیگی سے پہلے حذف کر دی گئی۔	/تلاش کریں۔	/گاڑی	980
تلاش کرنے والے کارٹ کو چھوڑ رہے ہیں۔	/	/چیک کریں۔	280
مکمل ہوم پیج سے تبدیلی تک کا سفر	/	(باہر نکلنا)	954

قبل از وقت ترک کرنا - انہوں نے ہوم پیج سے سائٹ کو مکمل طور پر چھوڑ دیا ہے۔

ہیٹ میپ سیلز کو کیسے پڑھیں:earliest(pageUrl)قطار = (entry page) ریکارڈ کیا گیا (latest(pageUrl))۔ کالم = (exit page) ریکارڈ کیا گیا ( Cell value = count(*) )۔

استفسار 7B میں، سیشنز کی تعداد ہے جنہوں نے عین آغاز + اختتامی مجموعہ کا اشتراک کیا۔ سیشن کا دورانیہ، جوابی وقت، یا درخواستوں کی تعداد نہیں۔

مثال: قطار / · col /cart = 1,840 کا مطلب ہے کہ ہوم پیج پر 1,840 سیشنز ہوئے ہیں، اور آخری ریکارڈ شدہ صفحہ /cart تھا۔ وہ مزید آگے نہیں گئے۔

10.5 سوال 7C - نتائج کی درجہ بندی کے ساتھ سیشن کے لحاظ سے

-- Query 7C: Per-session with outcome bucket (CASE classification)
-- Use for: segment-level analysis, inspecting individual sessions per outcome
-- Intermediate step --- run Query 7D to get the aggregated counts

SELECT
  session,
  earliest(pageUrl) AS entry_page,
  latest(pageUrl) AS exit_page,
  count(pageUrl) AS pages_visited,
  max(timestamp) - min(timestamp) AS session_duration_ms,
  filter(count(*), WHERE pageUrl LIKE '%/confirmation%') AS converted,
  CASE
    WHEN latest(pageUrl) LIKE '%/confirmation%' THEN 'converted'
    WHEN latest(pageUrl) LIKE '%/payment%' THEN 'payment_drop'
    WHEN latest(pageUrl) LIKE '%/checkout%' THEN 'checkout_drop'
    WHEN latest(pageUrl) LIKE '%/cart%' THEN 'cart_abandon'
    WHEN latest(pageUrl) LIKE '%/product/%' THEN 'browse_exit'
    ELSE 'early_exit'
  END AS journey_outcome
FROM PageView
WHERE appName="your-app-name"
FACET session
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'
LIMIT 1000

Query 7C تمام سیشنز کو ان کے ایگزٹ پیج کی بنیاد پر نامزد رزلٹ بکٹس میں ترتیب دینے کے لیے استفسار 7A میں ایک CASE بیان شامل کرتا ہے۔ یہ جمع کرنے سے پہلے ایک درمیانی مرحلہ ہے۔ آپ ہر نتیجہ کے زمرے میں انفرادی سیشنوں کو رول کرنے سے پہلے ان کا معائنہ کر سکتے ہیں۔

10.6 سوال 7D - کام کے بوجھ کے ماڈل میں نتائج کی تعداد (سب سے اہم) اس سیکشن میں لوڈ ٹیسٹنگ کے لیے Query 7D سب سے اہم سوال ہے۔ ہم تمام سیشنز کو چھ رزلٹ بکٹس میں سمیٹتے ہیں اور ہر ایک کے لیے گنتی، اوسط دورانیہ، اور اوسط صفحات واپس کرتے ہیں۔ کہ کل کالموں کا فیصد براہ راست VU وزن پر نقشہ بناتا ہے۔

-- Query 7D: Outcome counts for workload model
-- Use for: scenario weighting --- pct_of_total -> VU weight in load test
-- This is the query that replaces stakeholder opinion with production data

SELECT
  count(*) AS session_count
FROM PageView
WHERE appName="your-app-name"
FACET
  CASE
    WHEN latest(pageUrl) LIKE '%/confirmation%' THEN 'converted'
    WHEN latest(pageUrl) LIKE '%/payment%' THEN 'payment_drop'
    WHEN latest(pageUrl) LIKE '%/checkout%' THEN 'checkout_drop'
    WHEN latest(pageUrl) LIKE '%/cart%' THEN 'cart_abandon'
    WHEN latest(pageUrl) LIKE '%/product/%' THEN 'browse_exit'
    ELSE 'early_exit'
  END AS journey_outcome
SINCE '2025-11-28 11:00:00'
UNTIL '2025-11-28 11:59:59'

k6 یا JMeter کنفیگریشن میں۔

Query 7D سے آؤٹ پٹ جو ٹیسٹ کے منظر نامے VU وزن کو لوڈ کرنے کے لیے براہ راست نقشہ بناتا ہے:	سفر_نتیجہ	سیشن_کاؤنٹ	% بندوق	اوسط مدت	اوسط صفحہ
لوڈ ٹیسٹنگ کام	براؤز_اینڈ	7,214	25.4%	3 منٹ 08 سیکنڈ	2.8
صرف ایکسپلوریشن منظر نامہ - VU وزن 25%	کارٹ چھوڑ دو	5,380	18.9%	5 منٹ 12 سیکنڈ	4.1
کارٹ سے باہر نکلنے کا منظر - 19% VU وزن، کارٹ API زور	جلد ختم کرنا	4,694	16.5%	0 منٹ 52 سیکنڈ	1.1
باؤنس ٹریفک - 16% VU وزن، کم از کم تسلیم کرنے کا وقت	چیک آؤٹ_ڈراپ	4,396	15.5%	8 منٹ 44 سیکنڈ	5.9
ادائیگی ترک کرنا - VU وزن 15%، شپنگ فارم ٹیسٹ	تبدیل	3,706	13.1%	14 منٹ 20 سیکنڈ	8.2
کل فنل - 13% VU وزن، سب سے اہم راستہ	payment_delete	3,020	10.6%	11 منٹ 02 سیکنڈ	7.1

ادائیگی کی منسوخی - VU کا وزن 11%، ادائیگی API پر زور

10.7 ڈائنٹریس - یو ایس کیو ایل کی طرح usersession Dynatrace سفر کے تجزیہ کے لیے اہم فوائد پیش کرتا ہے۔

// Dynatrace USQL: per-session journey record with outcome
// usersession stores the full action array natively on the entity

SELECT
  sessionId,
  userActions.name[0] AS entry_action,
  userActions.name[userActionCount - 1] AS exit_action,
  COUNT(userActions) AS total_actions,
  duration AS session_ms,
  CASE WHEN userActions.name[userActionCount - 1]
    LIKE '%confirmation%' THEN 'converted'
    ELSE 'not_converted' END AS outcome
FROM usersession
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"
ORDER BY duration DESC
LIMIT 500

// Dynatrace USQL: heatmap counts --- no subquery needed
// userActions.name[0] = first action, [-1] = last action

SELECT
  userActions.name[0] AS entry_action,
  userActions.name[userActionCount - 1] AS exit_action,
  COUNT(*) AS session_count
FROM usersession
WHERE
  startTime > '2025-11-28T11:00:00'
  AND startTime < '2025-11-28T11:59:59'
  AND applicationType="BROWSER"
GROUP BY
  userActions.name[0],
  userActions.name[userActionCount - 1]
ORDER BY session_count DESC
LIMIT 50

ہستی پہلے سے ہی سیشن کی تاریخ میں کارروائیوں کی پوری ترتیب کو ذخیرہ کرتی ہے۔ پہلے اور آخری آپریشنز تک رسائی حاصل کی جا سکتی ہے سرنی اشاریہ سازی کے ذریعے سبکوریز یا ڈبل ​​FACETs کی ضرورت کے بغیر۔

11. نتیجہ

اگر آپ نے پوری طرح اس ٹیوٹوریل کی پیروی کی ہے، تو اب آپ کے پاس ایک ورک لوڈ ماڈل ہے جہاں تمام نمبرز (RPS ٹارگٹ، VU شمار، منظر نامے کے وزن، ٹیسٹ کی مدت) کو حقیقی ٹریفک کے لیے مخصوص مشاہداتی سوالات کے لیے واپس ٹریس کیا جاتا ہے۔

یہ ٹریس ایبلٹی لوڈ ٹیسٹنگ کو قابل اعتماد بناتی ہے۔ آپ انہیں بالکل دکھا سکتے ہیں کہ آپ نے 100 کا اندازہ لگانے کے بجائے 114 RPS کا انتخاب کیوں کیا اور آپ کی ادائیگی کا منظر آپ کو میٹنگ میں موجود کسی کے اندازہ کے بجائے VU کا 15% کیوں حاصل کرتا ہے۔

اگلا مرحلہ گٹ ہب سے چوٹی ورک لوڈ تجزیہ کار کو کلون کرنا ہے، اسے اپنے نئے ریلیک یا ڈائنیٹریس اکاؤنٹ کی طرف اشارہ کریں، اور اسے پچھلے سال کی چوٹی کی کھڑکی کے خلاف چلائیں۔ آؤٹ پٹ آپ کو بتاتا ہے کہ موجودہ لوڈ ٹیسٹ کنفیگریشن کو اصل ٹریفک کے مطابق بنایا گیا ہے یا کسی پلاننگ کال سے کسی کے بہترین اندازے کے مطابق۔ بنیادی اصول:

لوڈ ٹیسٹ کنفیگریشنز کی کسی بھی تعداد کو اصل پروڈکشن ڈیٹا کے خلاف سوالات کو ٹریک کرنا چاہیے۔ اگر آپ مشاہداتی ریکارڈ کی طرف اشارہ نہیں کر سکتے جو VUs، RPS گولز، یا منظر نامے کے وزن کی تعداد کو درست ثابت کرتا ہے، تو وہ نمبرز اندازے ہیں۔ یہ طریقہ کار زیادہ سے زیادہ تیاری کے بارے میں اندازے کو ختم کرتا ہے۔

11.1 فوری حوالہ: استفسار کی ترتیب مکمل کریں۔	قدم	ہدف	نیو ریلیک (NRQL)	Dynatrace (USQL)
حساب	1	چوٹی کا موسم	پیج ویوز/ٹرانزیکشنز FACET تاریخ (ٹائم اسٹیمپ)	صارف کا سیشن گروپ تاریخ تک
چوٹی کا موسم	2	چوٹی کا وقت	ٹرانزیکشن ٹائم سیریز 1 گھنٹہ	یوزر سیشن گروپ DATETIME تک
چوٹی کے اوقات	3	چوٹی منٹ/RPS	ٹرانزیکشن ٹائم سیریز 1 منٹ	صارف کا سیشن گروپ بذریعہ DATETIME
چوٹی منٹ + آر پی ایس	4	منظر نامے کا مرکب	لین دین کے چہرے کا نام + صفحہ دیکھیں چہرہ صفحہ URL	Useraction GROUP BY userActionName ORDER BY action_count DESC
% وزن	5	VU فی منظرنامہ	(منفرد شمار(سیشن) × اوسط(سیشن کا دورانیہ)) / 3600 FACET سفر کا نتیجہ	(شمار
× AVG (مدت)/1000) / 3600	منظر نامے کے لحاظ سے VUs	6	کل VU پولالگ شمار (سیشن)شمار(	)، AVG(مدت)/1000، (COUNT(
) × AVG(مدت)/1000)/3600 صارف کے سیشن سے	VU چھت	7A	سیشن کے لیے مخصوص ریکارڈنگ[0]سیشن منتخب کریں، پہلا/تازہ ترین (pageUrl)، شمار (pageUrl) PageView FACET سیشن سے[userActionCount-1] صارف ID، userActions.name منتخب کریں۔	userActions.name
صارف کے سیشن میں	1 قطار/سیشن	7B	پاتھ میٹرکس (ہیٹ میپ)[0]شمار[userActionCount-1]	ابتدائی FACET(pageUrl)، تازہ ترین(pageUrl) ORDER BY session_count DESC
userActions.name کے لحاظ سے گروپ کریں۔	userActions.name	ہیٹ میپ سیل کاؤنٹ	7C[userActionCount-1]فی سیشن + نتیجہ بالٹی	سیشن منتخب کریں، پہلا/تازہ ترین(pageUrl)، CASE(تازہ ترین(pageUrl)) PageView FACET سیشن سے Journey_outcome کے طور پر
صارف ID، userActions.name منتخب کریں۔	CASE(...) صارف سیشن سے سفر_نتیجہ کے طور پر	1 قطار/سیشن + نتیجہ کا لیبل	7D	نتیجے میں VU وزن