یو له هغو ستونزو څخه چې د څو محصولاتو سافټویر پلورونکي اکثرا ورسره مخ کیږي د انجینرانو - پراختیا کونکو ، ټیسټرانو ، او زیربناوو مدیرانو - نږدې هر ټیم کې د وړتیا نقل کول دي. دا په ګران انجنیرانو باندې هم پلي کیږي - د بار ازموینې په برخه کې متخصصین.
د دې پرځای چې خپلې مستقیمې دندې ترسره کړي او د بار ازموینې پروسې رامینځته کولو لپاره د دوی ځانګړي تجربې څخه کار واخلي ، میتودولوژي غوره کړئ ، مطلوب میټریکونه او د بار پروفایلونو سره سم اتوماتیک ازموینې ولیکئ ، انجینران اکثرا باید د ازموینې زیربنا له سکریچ څخه ځای په ځای کړي ، د بار کولو وسیلې تنظیم کړي او ځای په ځای کړي. پخپله د CI سیسټمونو کې، د راپورونو څارنه او خپرونه جوړه کړه.
تاسو کولی شئ په ازموینې کې د ځینې تنظیمي ستونزو حلونه ومومئ چې موږ یې په مثبت ټیکنالوژیو کې کاروو . او پدې کې به زه د "خدمت په توګه د بار ازموینې" (د خدمت په توګه د بار ازموینې) مفهوم په کارولو سره په عام CI پایپ لاین کې د بار ازموینې ادغام احتمال په اړه وغږیږم. تاسو به زده کړئ چې څنګه او د کوم ډاکر لوډ سرچینې عکسونه د CI پایپ لاین کې کارول کیدی شي؛ د جوړ شوي ټیمپلیټ په کارولو سره ستاسو د CI پروژې سره د بار سرچینې څنګه وصل کړئ؛ د ډیمو پایپ لاین د بار ازموینې چلولو او پایلو خپرولو لپاره څنګه ښکاري. مقاله ممکن په CI کې د سافټویر ازموینې انجینرانو او اتومات انجینرانو لپاره ګټور وي څوک چې د دوی د بار سیسټم جوړښت په اړه فکر کوي.
د مفهوم جوهر
د خدمت په توګه د بار ازموینې مفهوم د اپاچي JMeter ، Yandex.Tank او ستاسو خپل چوکاټونه په خپل سري دوامداره ادغام سیسټم کې د بار کولو وسیلو مدغم کولو وړتیا معنی لري. ډیمو به د GitLab CI لپاره وي، مګر اصول د ټولو CI سیسټمونو لپاره عام دي.
د خدمت په توګه د بار ازموینه د بار ازموینې لپاره مرکزي خدمت دی. د بار ازموینې په وقف شوي اجنټ پول کې پرمخ وړل کیږي، پایلې په اتوماتيک ډول د GitLab پاڼې، Influx DB او Grafana یا د ازموینې راپور ورکولو سیسټمونو کې خپریږي (TestRail، ReportPortal، او نور). اتومات او اندازه کول د امکان تر حده په ساده ډول پلي کیږي - د معمول gitlab-ci.yml ټیمپلیټ GitLab CI پروژه کې د اضافه کولو او پیرامیټریشن له لارې.
د دې تګلارې ګټه دا ده چې د CI ټول زیربناوې ، د بار اجنټان ، د بار سرچینو ډاکر عکسونه ، د ازموینې پایپ لاینونه ، او د راپورونو خپرول د مرکزي اتومات ډیپارټمنټ (DevOps انجینرانو) لخوا ساتل کیږي ، پداسې حال کې چې د بار ازموینې انجینران کولی شي خپلې هڅې د ازموینې پراختیا باندې تمرکز وکړي. او د دوی د پایلو تحلیل، پرته له دې چې د زیربناوو مسلو سره معامله وکړي.
د وضاحت د سادګۍ لپاره، موږ به فرض کړو چې د هدف غوښتنلیک یا د ازموینې لاندې سرور لا دمخه ځای په ځای شوی او تنظیم شوی دی (په Python، SaltStack، Ansible، او نور کې اتوماتیک سکریپټونه د دې لپاره کارول کیدی شي). بیا د خدمت په توګه د بار ازموینې ټوله مفهوم په دریو مرحلو کې فټ کیږي: چمتو کول، ازموینه، د راپورونو خپرول. په ډیاګرام کې نور توضیحات (ټول عکسونه د کلیک کولو وړ دي):
د بار په ازموینه کې بنسټیز مفهومونه او تعریفونه
کله چې د بار ازموینې ترسره کول، موږ هڅه کوو چې تعقیب یې کړو ، مناسب اصطلاحات او وړاندیز شوي میټریکونه وکاروئ. زه به د بار ازموینې کې د اصلي مفاهیمو او تعریفونو لنډ لیست وړاندې کړم.
د بارولو اجنټ - یو مجازی ماشین چې غوښتنلیک به یې په لاره واچول شي - د بار سرچینه (Apache JMeter، Yandex.Tank یا د ځان لیکل شوي بار ماډل).
د ازموینې هدف (هدف) - په سرور کې نصب شوی سرور یا غوښتنلیک چې د بار کولو تابع وي.
د ازموینې سناریو (د ازموینې قضیه) - د پیرامیټر شوي ګامونو مجموعه: د کاروونکو کړنې او د دې کړنو په اړه تمه شوي عکس العملونه ، د ټاکل شوي شبکې غوښتنو او ځوابونو سره ، د ټاکل شوي پیرامیټونو پورې اړه لري.
پروفایل یا بار پلان (پروفایل) - په (برخه 4.2.4، مخ. 43) د بار پروفایلونه میټریکونه تعریفوي کوم چې د یوې ځانګړې ازموینې لپاره مهم دي او د ازموینې پرمهال د بار پیرامیټونو بدلولو اختیارونه. تاسو کولی شئ په انځور کې د پروفایل مثالونه وګورئ.
ازموینه - یو سکریپټ چې د پیرامیټونو له مخکې ټاکل شوي سیټ سره.
د ازموینې پلان (د ازموینې پلان) - د ازموینو سیټ او د بار پروفایل.
ټیسټران (ټیسټرون) - د بشپړ اجرا شوي بار سناریو او ترلاسه شوي راپور سره د یوې ازموینې چلولو یو تکرار.
د شبکې غوښتنه (غوښتنه) - د HTTP غوښتنه د ایجنټ څخه هدف ته لیږل شوې.
د شبکې غبرګون (ځواب) - د HTTP ځواب د هدف څخه اجنټ ته لیږل شوی.
د HTTP ځواب کوډ (د HTTP ځوابونو حالت) - د غوښتنلیک سرور څخه معیاري ځواب کوډ.
معامله یو بشپړ د غوښتنې ځواب دوره ده. معامله د غوښتنې (غوښتنې) لیږلو له پیل څخه د ځواب (ځواب) ترلاسه کولو بشپړیدو پورې شمیرل کیږي.
د راکړې ورکړې حالت - ایا دا ممکنه وه چې د غوښتنې ځواب دوره په بریالیتوب سره بشپړه شي. که په دې دوره کې کومه تېروتنه وه، نو بیا ټوله معامله ناکامه ګڼل کیږي.
د غبرګون وخت - د غوښتنې (غوښتنې) لیږلو له پای څخه د ځواب ترلاسه کولو پیل پورې وخت (ځواب).
میټریکونه بار کړئ - د بار شوي خدمت ځانګړتیاوې او د بار اجنټ د بار ازموینې په پروسه کې ټاکل شوي.
د بار پیرامیټونو اندازه کولو لپاره اساسی میټریکونه
په میتودولوژي کې ځینې خورا عام کارول شوي او وړاندیز شوي (مخ 36، 52) میټریکونه په لاندې جدول کې ښودل شوي. د ایجنټ او هدف لپاره ورته میټریکونه په ورته کرښه کې لیست شوي دي.
د بار کولو اجنټ لپاره میټریکونه
د هدف سیسټم یا غوښتنلیک میټریکونه چې د بار لاندې ازمول کیږي
د vCPU او حافظه مؤقتي حافظه,
disk - د بار کولو اجنټ "اوسپنې" ځانګړتیاوې
سی پی یو, حافظه، د ډیسک کارول - د CPU ، حافظې او ډیسک بار کولو متحرکات
د ازموینې په بهیر کې. معمولا د فیصدي په توګه اندازه کیږي
اعظمي موجود ارزښتونه
د شبکې له لارې (په بار کولو اجنټ) - throughput
په سرور کې د شبکې انٹرفیس،
چیرې چې د بار کولو اجنټ نصب شوی.
معمولا په هره ثانیه کې په بایټ کې اندازه کیږي (bps)
د شبکې له لارې(په هدف) - د شبکې انٹرفیس بینډ ویت
په هدف سرور کې. معمولا په هره ثانیه کې په بایټ کې اندازه کیږي (bps)
مجازی کاروونکي- د مجازی کاروونکو شمیر،
د بار سناریو پلي کول او
د ریښتیني کارونکي عملونو تقلید
د مجازی کاروونکو حالتپاس شوي/ناکام/ټول — د بریالي شمېر او
د مجازی کاروونکو ناکام حالتونه
د بار سناریو لپاره، او همدارنګه د دوی ټول شمیر.
دا عموما تمه کیږي چې ټول کاروونکي د بشپړولو توان ولري
ستاسو ټولې دندې د بار پروفایل کې مشخص شوي.
هر ډول تېروتنه به پدې معنی وي چې یو ریښتینی کاروونکي به ونه توانیږي
ستاسو ستونزه حل کړئ کله چې د سیسټم سره کار کوئ
په هره ثانیه کې غوښتنې (دقیقې)- په هره ثانیه کې د شبکې غوښتنو شمیر (یا دقیقې).
د بار کولو اجنټ یوه مهمه ځانګړتیا دا ده چې دا څومره غوښتنې رامینځته کولی شي.
په حقیقت کې ، دا د مجازی کاروونکو لخوا غوښتنلیک ته د لاسرسي تقلید دی
په هره ثانیه کې ځوابونه (دقیقه)
- په هره ثانیه کې د شبکې ځوابونو شمیر (یا دقیقې).
د هدف خدمت یوه مهمه ځانګړتیا: څومره
سره پوښتنو ته ځوابونه تولید او لیږل
د بارولو اجنټ
د HTTP ځواب حالت- د مختلف ځواب کوډونو شمیر
د غوښتنلیک سرور څخه د بار اجنټ لخوا ترلاسه شوی.
د مثال په توګه، 200 OK معنی لري یو بریالي کال،
او 404 - دا چې سرچینه ونه موندل شوه
لطیسي (د ځواب وخت) - د پای څخه وخت
د ځواب (ځواب) ترلاسه کولو پیل کولو دمخه د غوښتنې (غوښتنې) لیږل.
معمولا په ملی ثانیو کې اندازه کیږي (ms)
د لیږد ځواب وخت- د یوې بشپړې معاملې وخت،
د غوښتنې او ځواب دورې بشپړول.
دا د غوښتنې لیږلو له پیل څخه وخت دی (غوښتنه)
د ځواب ترلاسه کولو تر بشپړیدو پورې (ځواب)
د راکړې ورکړې وخت په ثانیو (یا دقیقو) کې اندازه کیدی شي
په څو لارو کې: لږترلږه په پام کې ونیسئ،
اعظمي، اوسط او د مثال په توګه، 90 فیصده.
لږترلږه او اعظمي لوستل خورا ډیر دي
د سیسټم فعالیت حالت.
نهه فیصده تر ټولو عام کارول کیږي،
لکه څنګه چې دا ډیری کاروونکي ښیي،
په آرامۍ سره د سیسټم فعالیت په حد کې فعالیت کوي
په هره ثانیه کې راکړه ورکړه (دقیقه) - د بشپړو شمیر
په هره ثانیه کې راکړه ورکړه (دقیقه)
دا چې څومره غوښتنلیک د منلو وړ و او
غوښتنې پروسس کړئ او ځوابونه صادر کړئ.
په حقیقت کې، دا د سیسټم له لارې دی
د راکړې ورکړې حالت پاس / ناکام / ټول - شمیره
بریالي، ناکامه او د معاملو ټولیز شمیر.
د اصلي کاروونکو لپاره ناکامه
معامله به په حقیقت کې معنی ولري
د بار لاندې سیسټم سره کار کولو توان نلري
د بار ازموینې سکیمیک ډیاګرام
د بار ازموینې مفهوم خورا ساده دی او له دریو اصلي مرحلو څخه جوړ دی ، کوم چې ما دمخه یادونه کړې: د ازموینې راپور چمتو کول، دا د ازموینې اهدافو چمتو کول او د بار سرچینو لپاره پیرامیټرې تنظیم کول ، بیا د بار ازموینې اجرا کول او په پای کې د ازموینې راپور رامینځته کول او خپرول.
سکیماتیک یادښتونه:
- QA.Tester د بار ازموینې متخصص دی،
- هدف د هدف غوښتنلیک دی د کوم لپاره چې تاسو غواړئ د بار لاندې د هغې چلند وپیژنئ.
په ډیاګرام کې د ادارو، مرحلو او مرحلو طبقه بندي
پړاوونه او ګامونه
څه خبرې دي
په دروازه کې څه دي
محصول څه شی دی
چمتو کول: د ازموینې لپاره د چمتووالي مرحله
LoadParameters
ترتیب او پیل کول
کارونکی
د بارولو پیرامیټونه
د میترونو انتخاب او
د ازموینې پلان چمتو کول
(د پروفایل پورته کول)
لپاره دودیز انتخابونه
د بار اجنټ پیل کول
د ازموینې پلان
د ازموینې موخه
VM
د بادل ځای پرځای کول
مجازی ماشین سره
اړین ځانګړتیاوې
د بار اجنټ لپاره د VM تنظیمات
لپاره د اتوماتیک سکریپټ
د VM جوړول
VM ترتیب شوی
وريځ
این
د OS تنظیم او چمتو کول
لپاره چاپیریال
د بارولو اجنټ کار
لپاره د چاپیریال ترتیبات
د بارولو اجنټ
لپاره د اتوماتیک سکریپټ
د چاپیریال ترتیبات
چمتو چاپیریال:
OS، خدمتونه او غوښتنلیکونه،
د کار لپاره اړین
د بارولو اجنټ
LoadAgents
نصب، ترتیب او پیرامیټریزیشن
د بارولو اجنټ.
یا له دې څخه د ډاکر عکس ډاونلوډ کړئ
مخکې ترتیب شوی بار سرچینه
د سرچینې ډاکر عکس پورته کړئ
(YAT، JM یا پخپله لیکل شوی چوکاټ)
ترتیبات
د بارولو اجنټ
تنظیم او چمتو دی
د کار بار ایجنټ ته
ازموینه: د بار ازموینې د اجرا کولو مرحله. سرچینې د بار اجنټان دي چې د GitLab CI لپاره وقف شوي اجنټ حوضونو کې ګمارل شوي
بار
د بار کولو اجنټ پیل کول
د ټاکل شوي ازموینې پلان سره
او د بارولو پیرامیټونه
د کاروونکي اختیارونه
د پیل کولو لپاره
د بارولو اجنټ
د ازموینې پلان
د ازموینې موخه
د اعدام لوګو
بار ازموینې
د سیسټم لوګو
د هدف میټریکونو او بار ایجنټ کې د بدلون متحرکات
د اجنټانو چلول
د اجنټ اعدام
د ټیسټ سکریپټونو ډیری
د .. سره په سمون
پروفایل پورته کول
د اجنټ متقابل عمل
د ازموینې په موخه
د ازموینې پلان
د ازموینې موخه
ننوتونونه
د "خام" لوګو راټولول
د بار ازموینې پرمهال:
د بار کولو اجنټ فعالیت ریکارډونه
د ازموینې هدف حالت
او VM اجنټ چلوي
د اعدام لوګو
بار ازموینې
د سیسټم لوګو
میتریک
د ازموینې پرمهال د "خام" میټریکونو راټولول
د هدف میترونو کې د بدلونونو تحرک
او د بارولو اجنټ
راپور: د ازموینې راپور چمتو کولو مرحله
جنریټر
راټولول پروسس کول
د بارولو سیسټم او
د څارنې سیسټم "خام"
میټریک او لاګ
د راپور جوړول
د انسان د لوستلو وړ بڼه
د عناصرو سره ممکنه ده
شنونکي
د اعدام لوګو
بار ازموینې
د سیسټم لوګو
په میټریکونو کې د بدلونونو متحرکات
هدف او بار ایجنټ
پروسس شوي "خام" لاګونه
په مناسب شکل کې
بهرنۍ ذخیرې ته پورته کول
د جامد بار راپور،
د انسان د لوستلو وړ
د خپرېدو
د راپور خپرول
د بار په اړه
په بهر کې ازموینه
خدمت
پروسس شوی "خام"
په مناسب شکل کې ننوتل
بهر ته د پورته کولو لپاره
ذخیره
په بهر کې خوندي شوی
د ذخیره کولو راپورونه
بار، مناسب
د انسان تحلیل لپاره
په CI ټیمپلیټ کې د بار سرچینو سره نښلول
راځئ چې عملي برخې ته لاړ شو. زه غواړم وښیم چې څنګه په شرکت کې ځینې پروژې موږ د خدمت په توګه د بار ازموینې مفهوم پلي کړی.
لومړی ، زموږ د DevOps انجینرانو په مرسته ، موږ په GitLab CI کې د اجنټانو وقف شوی حوض رامینځته کړ ترڅو د بار ازموینې پرمخ بوځي. د دې لپاره چې دوی د نورو سره په ټیمپلیټونو کې ګډوډ نه کړي، لکه د اسمبلۍ حوض، موږ دې استازو ته ټاګونه اضافه کړل، : بار تاسو کولی شئ کوم بل د پوهیدو وړ ټاګونه وکاروئ. دوی پوښتنه کوي د GitLab CI چلونکي.
د هارډویر په واسطه د اړتیا وړ بریښنا څنګه معلوم کړئ؟ د بار اجنټانو ځانګړتیاوې - د vCPU، رام او ډیسک کافي شمیر - د دې حقیقت پراساس محاسبه کیدی شي چې ډاکر، پایتون (د Yandex.Tank لپاره)، GitLab CI اجنټ، جاوا (د اپاچي JMeter لپاره) باید په اجنټ کې روان وي. . د JMeter لاندې جاوا لپاره، دا هم سپارښتنه کیږي چې لږترلږه 512 MB RAM وکاروئ او د پورتنۍ حد په توګه، .
پدې توګه ، زموږ د تجربې پراساس ، موږ د بار اجنټانو لپاره لږترلږه 4 vCPUs ، 4 GB رام ، 60 GB SSD کارولو وړاندیز کوو. د شبکې کارت له لارې د بار پروفایل اړتیاو پراساس ټاکل کیږي.
موږ په عمده توګه دوه د بار سرچینې کاروو - د اپاچي JMeter او Yandex.Tank ډاکر انځورونه.
د بار ازموینې لپاره د Yandex څخه د خلاصې سرچینې وسیله ده. د دې ماډلر جوړښت د فینټم د لوړ فعالیت اسینکرونس هټ پراساس د HTTP غوښتنې جنریټر پراساس دی. ټانک د SSH پروتوکول له لارې د ازموینې لاندې د سرور سرچینو په اړه جوړ شوی نظارت لري ، کولی شي په اوتومات ډول د ټاکل شوي شرایطو لاندې ازموینه ودروي ، کولی شي پایلې دواړه په کنسول او ګرافونو کې ښکاره کړي ، تاسو کولی شئ خپل ماډلونه وصل کړئ. د فعالیت پراخولو لپاره دې ته. په لاره کې، موږ ټانک کارولی و کله چې دا لاهم اصلي جریان نه و. په مقاله کې "» تاسو کولی شئ هغه کیسه ولولئ چې څنګه موږ په 2013 کې د بار وړلو ازموینه ترسره کړه زموږ د شرکت محصولاتو څخه یو دی.
د اپاچی څخه د خلاصې سرچینې بار ازموینې وسیله ده. دا د دواړو جامد او متحرک ویب غوښتنلیکونو ازموینې لپاره په مساوي ډول ښه کارول کیدی شي. JMeter د غوښتنلیکونو سره د متقابل عمل کولو ډیری پروتوکولونو او لارو ملاتړ کوي: HTTP، HTTPS (جاوا، نوډ جے ایس، پی ایچ پی، ASP.NET، او نور)، SOAP / REST ویب خدمتونه، FTP، TCP، LDAP، SMTP (S)، POP3 ( S)) او IMAP(S)، د JDBC له لارې ډیټابیسونه کولی شي د شیل کمانډونه اجرا کړي او د جاوا شیانو سره کار وکړي. JMeter د ازموینې پلانونو رامینځته کولو ، ډیبګ کولو او اجرا کولو لپاره IDE لري. د جاوا سره مطابقت لرونکي عملیاتي سیسټم (لینکس، وینډوز، میک OS X) کې د کمانډ لاین عملیاتو لپاره CLI هم شتون لري. وسیله کولی شي په متحرک ډول د HTML ازموینې راپور رامینځته کړي.
زموږ په شرکت کې د کارونې اسانتیا لپاره ، د چاپیریال بدلولو او اضافه کولو لپاره پخپله د ازموینې کونکو وړتیا لپاره ، موږ د داخلي ته د خپرولو سره په GitLab CI کې د بار سرچینو ډاکر عکسونه جوړ کړل. . دا د بار ازموینې لپاره په پایپ لاینونو کې د دوی نښلول ګړندي او اسانه کوي. د GitLab CI له لارې راجسټری ته د ډاکر فشار ورکولو څرنګوالی - وګورئ .
موږ دا بنسټیز ډاکر فایل د Yandex.Tank لپاره اخیستی:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]او د اپاچي JMeter لپاره دا یو:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]تاسو کولی شئ په مقاله کې ولولئ چې زموږ د دوامداره ادغام سیسټم څنګه کار کوي "".
کينډۍ او پایپ لاین
د بار ازموینې ترسره کولو لپاره د ټیمپلیټ یوه بیلګه په پروژه کې شتون لري . د تاسو کولی شئ د ټیمپلیټ کارولو لپاره لارښوونې ولولئ. پخپله ټیمپلیټ کې (دوتنه ) د هغه څه په اړه یادداشتونه شتون لري چې هر ګام یې مسؤل دی.
ټیمپلیټ خورا ساده دی او د بار ازموینې درې مرحلې ښیې چې پورته په ډیاګرام کې تشریح شوي: چمتو کول ، ازموینه او خپرول. د دې لپاره مسؤل دی : چمتو کول، ازموینه او راپور ورکول.
- مرحله باید د ازموینې اهدافو دمخه تنظیم کولو یا د دوی شتون چیک کولو لپاره وکارول شي. د بار سرچینو لپاره چاپیریال تنظیم کولو ته اړتیا نلري ، دوی د ډاکر عکسونو په توګه دمخه جوړ شوي او د ډاکر راجسټری کې پوسټ شوي: یوازې د ازموینې مرحله کې مطلوب نسخه مشخص کړئ. مګر تاسو کولی شئ دوی بیا جوړ کړئ او خپل بدل شوي عکسونه جوړ کړئ.
- مرحله د بار سرچینې مشخص کولو، ازموینې چلولو، او د ازموینې آثارو ذخیره کولو لپاره کارول کیږي. تاسو کولی شئ د بار کولو کومه سرچینه وټاکئ: Yandex.Tank، Apache JMeter، ستاسو خپل، یا ټول یوځای. د غیر ضروري سرچینو غیر فعالولو لپاره، یوازې تبصره وکړئ یا دنده حذف کړئ. د بار سرچینو لپاره د ننوتلو نقطې:
- د Yandex.Tank لپاره د لانچ پیرامیټونه په کې مشخص شوي دي.,
- د Apache JMeter د پیل کولو پیرامیټونه په فایل کې مشخص شوي .
یادونه: د مجلس ترتیب کولو ټیمپلیټ د CI سیسټم سره تعامل تنظیم کولو لپاره کارول کیږي او پدې کې د ازموینې منطق ځای په ځای کولو معنی نلري. د ازموینو لپاره، د ننوتلو ځای مشخص شوی، چیرته چې د کنټرول باش سکریپټ موقعیت لري. د ازموینو د چلولو طریقه، د راپورونو تولید، او د ازموینې سکریپټونه پخپله باید د QA انجنیرانو لخوا پلي شي. په ډیمو کې، د دواړو بار سرچینو لپاره، د Yandex اصلي پاڼې غوښتنه د ساده ازموینې په توګه کارول کیږي. سکریپټونه او د ازموینې پیرامیټونه په لارښود کې دي .
- په مرحله کې تاسو اړتیا لرئ تشریح کړئ چې څنګه د ازموینې په مرحله کې ترلاسه شوي ازموینې پایلې بهرنۍ زیرمو ته خپاره کړئ، د بیلګې په توګه، د GitLab پاڼې یا ځانګړي راپور ورکولو سیسټمونو ته. د GitLab مخونه اړتیا لري چې ./public لارښود خالي نه وي او لږترلږه د index.html فایل ولري وروسته له دې چې ازموینې پای ته ورسیږي. تاسو کولی شئ د GitLab پا pages خدماتو باریکیو په اړه ولولئ. .
د ډیټا صادرولو څرنګوالي مثالونه:
- له JMeter څخه ,
- له Yandex.Tank څخه .
د تنظیم کولو لارښوونې پوسټ کول:
- د HTML احصایې په کې ,
- InfluxDB ته او بیا ته .
د ډیمو مثال کې، پایپ لاین د بار ازموینې او دوه بار سرچینو سره (تاسو کولی شئ غیر ضروري غیر فعال کړئ) داسې ښکاري:
Apache JMeter کولی شي پخپله د HTML راپور تولید کړي، نو دا د معیاري وسیلو په کارولو سره د GitLab پاڼو کې د خوندي کولو لپاره خورا ګټور دی. دا د اپاچي JMeter راپور داسې ښکاري:
د Yandex.Tank لپاره د ډیمو مثال کې، تاسو به یوازې وګورئ د GitLab پاڼو لپاره برخه کې. د ازموینې په جریان کې ، ټانک کولی شي پایلې د InfluxDB ډیټابیس ته خوندي کړي ، او له هغه ځایه یې ښودل کیدی شي ، د مثال په توګه ، په ګرافانا کې (تنظیم په فایل کې ترسره کیږي ). دا د ټانک راپور په ګرافانا کې څنګه ښکاري:
لنډیز
په مقاله کې ، ما د "د خدمت په توګه د بار ازموینې" مفکورې په اړه خبرې وکړې (د خدمت په توګه د بار ازموینه). اصلي مفکوره دا ده چې د بار اجنټانو دمخه ترتیب شوي حوضونو زیربنا وکاروئ ، د بار سرچینو ډاکر عکسونه ، د راپور ورکولو سیسټمونه او پایپ لاین چې دوی د ساده .gitlab-ci.yml ټیمپلیټ پراساس په GitLab CI کې ترکیب کوي (مثال ). دا ټول د اتومات انجینرانو د کوچني ټیم لخوا ملاتړ کیږي او د محصول ټیمونو په غوښتنه تکرار شوي. زه امید لرم چې دا به تاسو سره ستاسو په شرکت کې د ورته سکیم چمتو کولو او پلي کولو کې مرسته وکړي. له توجه مو مننه!
PS زه غواړم چې زموږ په شرکت کې د خدمت په توګه د بار ازموینې مفکورې پلي کولو کې تخنیکي مرستې لپاره زما همکارانو ، سرګي کوربانوف او نیکولای یوسیف څخه ډیره مننه وکړم.
لیکوال: - مرستیال په مثبت ټیکنالوژیو کې د ټیکنالوژیو او پراختیا پروسې مشر (DevOps)
سرچینه: www.habr.com