เครื่องมือทดสอบ LoadRunner: Archiแผนภาพโครงสร้างและส่วนประกอบ

⚡ สรุปอย่างชาญฉลาด

LoadRunner คือเครื่องมือทดสอบประสิทธิภาพระดับองค์กร ซึ่งปัจจุบันจำหน่ายโดย OpenTextซึ่งจำลองผู้ใช้งานเสมือนจริงหลายพันคนทั่วทั้ง VuGen, Controller, ตัวสร้างโหลด และการวิเคราะห์ เพื่อเปิดเผยจุดคอขวดก่อนที่ปริมาณการใช้งานจริงจะพบเจอ

  • 🔘 ต้นกำเนิด: ถูกสร้างขึ้นโดย Mercury Interactive ซึ่งถูกซื้อกิจการโดย HP จากนั้นโดย Micro Focus และปัจจุบันคือ Interactive OpenText.
  • ☑️ ครอบคลุม: หนึ่งในคลังโปรโตคอลที่ครอบคลุมมากที่สุด ตั้งแต่ HTTP และ Ajax ไปจนถึง SAP, Oracle และซิตริกซ์
  • VuGen: บันทึกข้อมูลการรับส่งระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ลงในสคริปต์ VUser ซึ่งจะจำลองกระบวนการทางธุรกิจ
  • 🧪 ควบคุม: กำหนดรูปแบบของสถานการณ์ — จำนวนผู้ใช้เสมือน (VUser), การเพิ่มจำนวนผู้ใช้ (ramp-up), ตัวฉีด (injector), การปลอมแปลง IP และการตรวจสอบ SLA
  • 🛠️ เครื่องกำเนิดไฟฟ้า: กระจาย VUsers ไปยังเครื่องต่างๆ เพื่อให้ Controller ไม่ทำให้ค่าที่วัดผิดเพี้ยนไป
  • 📊 วิเคราะห์: แปลงข้อมูลดิบที่ได้ให้เป็นกราฟเพื่อระบุจุดคอขวดในระบบขณะที่มีภาระงานสูง

ส่วนประกอบและเครื่องมือทดสอบ LoadRunner Archiเทคเจอร์

LoadRunner คืออะไร?

LoadRunner คือ การทดสอบประสิทธิภาพ เครื่องมือซึ่งได้รับการคิดค้นโดย Mercury LoadRunner ก่อตั้งขึ้นโดย Interactive ในปี 1999 ต่อมาถูก HP เข้าซื้อกิจการในปี 2006 และธุรกิจซอฟต์แวร์ของ HP ได้ควบรวมกิจการกับ Micro Focus ในข้อตกลงที่ประกาศในปี 2016 และเสร็จสมบูรณ์ในปี 2017

หมายเหตุเกี่ยวกับแบรนด์: OpenText การเข้าซื้อกิจการ Micro Focus เสร็จสมบูรณ์ในเดือนมกราคม 2023เครื่องมือนี้ไม่ได้วางจำหน่ายในชื่อ HP หรืออีกต่อไปแล้ว Micro Focus LoadRunnerLoadRunner Professional พร้อมใช้งานแล้ว OpenText วิศวกรรมประสิทธิภาพระดับมืออาชีพ LoadRunner Enterprise คือ OpenText วิศวกรรมประสิทธิภาพระดับองค์กร และ LoadRunner Cloud คือ OpenText วิศวกรรมประสิทธิภาพหลัก ชื่อส่วนประกอบด้านล่าง — VuGen, ตัวควบคุม, เครื่องกำเนิดโหลด และการวิเคราะห์ — ยังคงไม่เปลี่ยนแปลง

LoadRunner รองรับเครื่องมือพัฒนา เทคโนโลยี และโปรโตคอลการสื่อสารที่หลากหลาย มีไลบรารีโปรโตคอลที่ครอบคลุมมากที่สุดแห่งหนึ่งในตลาดสำหรับการทดสอบประสิทธิภาพ ผลลัพธ์การทดสอบประสิทธิภาพที่ได้จากซอฟต์แวร์ LoadRunner จะถูกนำไปใช้เป็นเกณฑ์มาตรฐานเปรียบเทียบกับเครื่องมืออื่นๆ

วิดีโอ LoadRunner

รับชมวิดีโอด้านล่างเพื่อทำความรู้จักกับ LoadRunner อย่างรวดเร็วก่อนที่จะเริ่มศึกษาองค์ประกอบต่างๆ

ทำไมต้องโหลดรันเนอร์?

LoadRunner ไม่เพียงแต่เป็นเครื่องมือบุกเบิกในด้านการทดสอบประสิทธิภาพเท่านั้น แต่ยังคงเป็นหนึ่งในผู้นำตลาดในด้านการทดสอบประสิทธิภาพ และยังคงเป็นจุดอ้างอิงที่องค์กรหลายแห่งใช้เป็นเกณฑ์มาตรฐาน

ความครอบคลุมของโปรโตคอลเป็นเหตุผลที่ชัดเจนที่สุดที่ทีมต่างๆ เลือกใช้ ดังที่แผนผังส่วนประกอบด้านล่างแสดงให้เห็น

LoadRunner ถูกวางตำแหน่งให้เป็นเครื่องมือทดสอบประสิทธิภาพสำหรับแอปพลิเคชันระดับองค์กร

โดยทั่วไปแล้ว เครื่องมือ LoadRunner รองรับ RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex และ Silverlight ฯลฯ), มือถือ, SAP, Oracle, นางสาว SQL เซิร์ฟเวอร์, Citrix, RTE, Mail และเหนือสิ่งอื่นใด, Windows ซ็อกเก็ต เครื่องมือคู่แข่งไม่กี่ตัวเท่านั้นที่สามารถนำเสนอโปรโตคอลที่หลากหลายเช่นนี้ได้ในเครื่องมือเดียว ดังที่รายการโปรโตคอลด้านล่างแสดงให้เห็น

โปรโตคอลแอปพลิเคชันต่างๆ ที่ LoadRunner รองรับ

สิ่งที่ทำให้การเลือกใช้ LoadRunner ในการทดสอบซอฟต์แวร์น่าเชื่อถือยิ่งขึ้นก็คือ ความน่าเชื่อถือของเครื่องมือนี้ LoadRunner ได้รับการยอมรับมาอย่างยาวนาน และคุณมักจะพบว่าลูกค้าใช้ LoadRunner ในการตรวจสอบความถูกต้องของผลการทดสอบประสิทธิภาพของคุณ คุณจะรู้สึกสบายใจหากคุณใช้ LoadRunner สำหรับการทดสอบประสิทธิภาพอยู่แล้ว

ซอฟต์แวร์ LoadRunner มีการบูรณาการอย่างแน่นหนากับเครื่องมืออื่นๆ ในชุดเดียวกัน ได้แก่ Unified Functional Testing (เดิมที) QTPปัจจุบันจำหน่ายในชื่อ OpenText การทดสอบการทำงาน) และ ALM (การจัดการวงจรชีวิตแอปพลิเคชัน) OpenText ALM/Quality Center) — ซึ่งช่วยให้คุณสามารถดำเนินการกระบวนการทดสอบแบบครบวงจรได้

LoadRunner ทำงานบนหลักการจำลองผู้ใช้เสมือน (Virtual Users) บนแอปพลิเคชันเป้าหมาย ผู้ใช้เสมือนเหล่านี้ หรือเรียกอีกอย่างว่า VUsers จะจำลองคำขอของไคลเอ็นต์และคาดหวังการตอบกลับที่สอดคล้องกันเพื่อส่งผ่านธุรกรรม

ทำไมคุณต้องมีการทดสอบประสิทธิภาพ?

ตัวเลขประมาณการในอุตสาหกรรมด้านล่างนี้เป็นตัวเลขที่ถูกอ้างถึงอย่างกว้างขวางและมีมาตั้งแต่ช่วงต้นทศวรรษ 2010 แต่รูปแบบที่อธิบายไว้ยังคงไม่เปลี่ยนแปลง: หน้าเว็บที่โหลดช้าทำให้เสียค่าใช้จ่าย

มีการประเมินว่าเว็บไซต์มีประสิทธิภาพการทำงานต่ำ ทำให้สูญเสียรายได้ไปถึง 4.4 พันล้านดอลลาร์ต่อปี

ในยุค Web 2.0 ปัจจุบัน ผู้ใช้จะออกจากเว็บไซต์ทันทีหากเว็บไซต์ไม่ตอบสนองภายใน 8 วินาที ลองนึกภาพว่าคุณต้องรอ 5 วินาทีขณะค้นหาอะไรบางอย่าง Google หรือการส่งคำขอเป็นเพื่อนในเฟซบุ๊ก ผลกระทบจากการหยุดชะงักการทำงานมักร้ายแรงกว่าที่คิดไว้มาก มีตัวอย่างที่รู้จักกันดี เช่น กรณีที่เกิดขึ้นกับระบบธนาคารออนไลน์ของธนาคารแห่งอเมริกา Amazon บริการเว็บ, อินทอยต์ และแบล็กเบอร์รี่

จากข้อมูลของ Dun & Bradstreet บริษัทใน Fortune 500 กว่า 59% ประสบปัญหาเครื่องหยุดทำงานโดยเฉลี่ย 1.6 ชั่วโมงต่อสัปดาห์ หากพิจารณาว่าบริษัท Fortune 500 ที่มีพนักงานอย่างน้อย 10,000 คน จ่ายค่าแรงชั่วโมงละ 56 ดอลลาร์ ต้นทุนค่าแรงที่เกิดจากเครื่องหยุดทำงานสำหรับองค์กรดังกล่าวจะอยู่ที่ 896,000 ดอลลาร์ต่อสัปดาห์ หรือมากกว่า 46 ล้านดอลลาร์ต่อปี

ใช้เวลาหยุดทำงานเพียง 5 นาทีเท่านั้น Googleคาดว่าการปิดโดเมน .com ในเดือนสิงหาคม 2013 ทำให้บริษัทผู้ให้บริการค้นหาข้อมูลรายใหญ่ต้องเสียค่าใช้จ่ายสูงถึง 545,000 ดอลลาร์สหรัฐ

มีการประเมินว่าบริษัทต่างๆ สูญเสียยอดขายมูลค่า 1,100 ดอลลาร์ต่อวินาทีในช่วงที่ผ่านมา Amazon บริการเว็บขัดข้อง

เมื่อองค์กรนำระบบซอฟต์แวร์ไปใช้งาน องค์กรอาจเผชิญกับสถานการณ์ต่างๆ มากมายที่อาจทำให้ประสิทธิภาพลดลงได้ ปัจจัยหลายประการทำให้ประสิทธิภาพลดลง ตัวอย่างได้แก่:

  • เพิ่มจำนวนบันทึกที่มีอยู่ในฐานข้อมูล
  • เพิ่มจำนวนคำขอพร้อมกันที่ส่งมายังระบบ
  • จำนวนผู้ใช้งานที่เข้าถึงระบบพร้อมกันมีมากขึ้นเมื่อเทียบกับในอดีต

อย่างไรก็ตาม ไม่ใช่ว่าทุกใบสมัครจะเป็นผู้ที่เหมาะสม โหลดการทดสอบ โปรแกรมนี้มุ่งเป้าไปที่ระบบไคลเอ็นต์-เซิร์ฟเวอร์และผู้ใช้หลายคน ดังนั้นยูทิลิตี้เดสก์ท็อปสำหรับผู้ใช้คนเดียวเช่นตัวอย่างด้านล่างจึงไม่คุ้มค่าที่จะทดสอบประสิทธิภาพ

โปรแกรมยูทิลิตี้บนเดสก์ท็อปสำหรับผู้ใช้คนเดียว ซึ่งไม่เหมาะสำหรับการทดสอบประสิทธิภาพ

LoadRunner คืออะไร Archiเทคเจอร์?

โดยทั่วไปแล้ว โครงสร้างของ LoadRunner นั้นซับซ้อน แต่เข้าใจง่าย แผนภาพโครงสร้างของ LoadRunner ด้านล่างแสดงให้เห็นว่าส่วนประกอบทั้งสี่ทำงานร่วมกันอย่างไร

แผนภาพสถาปัตยกรรม LoadRunner แสดง VuGen, Controller, เครื่องกำเนิดโหลด และการวิเคราะห์

สมมติว่าคุณได้รับมอบหมายให้ตรวจสอบประสิทธิภาพของ Amazon.com สำหรับผู้ใช้ 5000 คน

ในสถานการณ์จริง ผู้ใช้ทั้ง 5000 คนจะไม่เข้ามาใช้งานเฉพาะหน้าแรกเท่านั้น แต่จะกระจายอยู่ตามส่วนต่างๆ ของเว็บไซต์ ดังนั้นเราจะจำลองความแตกต่างนี้ได้อย่างไร?

วูเจน

VuGen หรือ ผู้ใช้เสมือน Generator VuGen คือ IDE (Integrated Development Environment) หรือโปรแกรมแก้ไขโค้ดที่มีฟังก์ชันการทำงานครบครัน VuGen ใช้ในการจำลองพฤติกรรมของระบบภายใต้ภาระงานหนัก (System Under Load หรือ SUL) VuGen มีฟีเจอร์ "การบันทึก" ซึ่งบันทึกการสื่อสารระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ในรูปแบบของสคริปต์โค้ด – หรือที่เรียกว่า สคริปต์ สคริปต์ VUser.

จากตัวอย่างข้างต้น VuGen สามารถบันทึกเพื่อจำลองกระบวนการทางธุรกิจต่อไปนี้ได้:

  • ท่องหน้าผลิตภัณฑ์ของ Amazonด้วย.
  • Checkout
  • การประมวลผลการชำระเงิน
  • กำลังตรวจสอบหน้า MyAccount

เมื่อสคริปต์ทำงานได้อย่างราบรื่นแล้ว โดยปกติจะต้องดักจับค่าเซิร์ฟเวอร์แบบไดนามิกด้วย ความสัมพันธ์ ก่อนที่จะสามารถขยายขนาดได้

ตัวควบคุม

เมื่อสคริปต์ VUser เสร็จสมบูรณ์แล้ว ตัวควบคุม เป็นหนึ่งในส่วนประกอบหลักของ LoadRunner ซึ่งควบคุมการจำลองโหลดโดยการจัดการ เช่น:

  • จำนวน VUsers ที่จะจำลองเทียบกับแต่ละกระบวนการทางธุรกิจหรือกลุ่ม VUser
  • พฤติกรรมของ VUser (เพิ่มขึ้น, ลดลง, พร้อมกันหรือพร้อมกัน ฯลฯ)
  • ลักษณะของสถานการณ์โหลด เช่น ชีวิตจริงหรือมุ่งเน้นเป้าหมาย หรือการตรวจสอบ SLA
  • ควรใช้หัวฉีดตัวไหน จำนวน VUsers ต่อหัวฉีดแต่ละตัว
  • เรียงผลเป็นระยะ
  • การปลอมแปลง IP
  • การรายงานข้อผิดพลาด
  • การรายงานธุรกรรม ฯลฯ

ยกตัวอย่างจากกรณีของเรา ตัวควบคุม (Controller) จะเพิ่มพารามิเตอร์ต่อไปนี้ลงในสคริปต์ VuGen:

  1. มีผู้ใช้งาน 3500 คนกำลังเข้าชมหน้าผลิตภัณฑ์ของ Amazonด้วย.
  2. มีผู้ใช้งาน 750 คนอยู่ในขั้นตอนชำระเงิน
  3. ผู้ใช้งาน 500 รายกำลังดำเนินการประมวลผลการชำระเงิน
  4. มีผู้ใช้งาน 250 รายที่ตรวจสอบหน้าบัญชีของฉันหลังจากที่ผู้ใช้งาน 500 รายทำการชำระเงินเสร็จสิ้นแล้วเท่านั้น

ยังมีสถานการณ์ที่ซับซ้อนกว่านี้อีก:

  • เริ่มต้น 5 VUsers ทุกๆ 2 วินาทีจนกระทั่งโหลดได้ 3500 VUsers (surfing Amazon หน้าผลิตภัณฑ์) ได้แล้ว
  • ทำซ้ำเป็นเวลา 30 นาที
  • ระงับการวนซ้ำสำหรับ 25 VUsers
  • เริ่มระบบผู้ใช้เสมือน 20 รายใหม่
  • เริ่มต้นผู้ใช้ 2 คน (ในการชำระเงิน การประมวลผลการชำระเงิน หน้าบัญชีของฉัน) ทุกวินาที
  • 2500 VUsers จะถูกสร้างขึ้นที่เครื่อง A
  • 2500 VUsers จะถูกสร้างขึ้นที่ Machine B

เครื่องจักรตัวแทน/โหลด Generators/หัวฉีด

ตัวควบคุม LoadRunner มีหน้าที่จำลองผู้ใช้เสมือน (VUser) นับพันราย ซึ่งผู้ใช้เสมือนเหล่านี้ใช้ทรัพยากรฮาร์ดแวร์ เช่น โปรเซสเซอร์และหน่วยความจำ ทำให้เกิดข้อจำกัดบนเครื่องที่ใช้จำลอง นอกจากนี้ ตัวควบคุมยังจำลองผู้ใช้เสมือนเหล่านี้จากเครื่องเดียวกัน (เครื่องที่ตัวควบคุมตั้งอยู่) ดังนั้นผลลัพธ์อาจไม่แม่นยำ เพื่อแก้ไขปัญหานี้ ผู้ใช้เสมือนทั้งหมดจึงถูกกระจายไปยังเครื่องต่างๆ ที่เรียกว่า LoadRunner Generators หรือโหลดหัวฉีด

ตามแนวทางปฏิบัติทั่วไป คอนโทรลเลอร์จะอยู่บนเครื่องอื่นและมีการจำลองโหลดจากเครื่องอื่น ขึ้นอยู่กับโปรโตคอลของสคริปต์ VUser และข้อมูลจำเพาะของเครื่อง อาจจำเป็นต้องใช้ Load Injector จำนวนหนึ่งสำหรับการจำลองแบบเต็มรูปแบบ ตัวอย่างเช่น VUsers สำหรับสคริปต์ HTTP จะต้องใช้ 2-4MB ต่อ VUser สำหรับการจำลอง ดังนั้น เครื่อง 4 เครื่องที่มี RAM 4 GB แต่ละเครื่องจะต้องจำลองโหลด 10,000 VUsers

โดยยกตัวอย่างเปรียบเทียบจากกรณีของเรา Amazon ตัวอย่างเช่น ผลลัพธ์ของส่วนประกอบนี้คือ VUsers จำนวน 5000 ราย ซึ่งแบ่งออกเป็นสองหัวฉีด: 2500 รายสร้างบนเครื่อง A และ 2500 รายบนเครื่อง B

การวิเคราะห์

เมื่อการจำลองการโหลดเสร็จสิ้น บทบาทของ... การวิเคราะห์ ส่วนประกอบของ LoadRunner เข้ามามีบทบาท

ในระหว่างการดำเนินการ ตัวควบคุมจะสร้างดัมพ์ของผลลัพธ์ในรูปแบบ Raw และมีข้อมูลเช่น LoadRunner เวอร์ชันใดที่สร้างดัมพ์ผลลัพธ์นี้ และการกำหนดค่าคืออะไร

ข้อผิดพลาดและข้อยกเว้นทั้งหมดจะถูกบันทึกไว้ใน Microsoft เข้าถึงฐานข้อมูลชื่อ output.mdb คอมโพเนนต์การวิเคราะห์จะอ่านไฟล์ฐานข้อมูลนี้เพื่อทำการวิเคราะห์ประเภทต่างๆ และสร้างกราฟ

กราฟเหล่านี้แสดงแนวโน้มต่างๆ เพื่อทำความเข้าใจสาเหตุของข้อผิดพลาดและความล้มเหลวภายใต้ภาระงาน จึงช่วยพิจารณาว่าจำเป็นต้องมีการปรับให้เหมาะสมใน SUL, Server (เช่น JBoss, Oracle) หรือโครงสร้างพื้นฐาน

ด้านล่างนี้คือตัวอย่างที่แสดงให้เห็นว่าแบนด์วิดท์อาจเป็นคอขวดได้อย่างไร สมมติว่าเว็บเซิร์ฟเวอร์มีความจุ 1 Gbps แต่ปริมาณการรับส่งข้อมูลเกินความจุนี้ ทำให้ผู้ใช้รายถัดไปได้รับผลกระทบ เพื่อตรวจสอบว่าระบบรองรับความต้องการดังกล่าวได้หรือไม่ วิศวกรด้านประสิทธิภาพจำเป็นต้องวิเคราะห์พฤติกรรมของแอปพลิเคชันภายใต้ภาระงานที่ผิดปกติ ด้านล่างนี้คือกราฟที่ LoadRunner สร้างขึ้นเพื่อแสดงแบนด์วิดท์

กราฟการวิเคราะห์ LoadRunner แสดงให้เห็นว่าแบนด์วิดท์เป็นคอขวดด้านประสิทธิภาพ

วิธีทำการทดสอบประสิทธิภาพ

แผนงานการทดสอบประสิทธิภาพสามารถแบ่งออกได้เป็น 5 ขั้นตอนหลัก โดยสรุปไว้ในแผนงานด้านล่างนี้:

  1. การวางแผนสำหรับการทดสอบโหลด
  2. สร้างสคริปต์ VuGen
  3. การสร้างสถานการณ์
  4. การดำเนินการตามสถานการณ์
  5. การวิเคราะห์ผลลัพธ์ (ตามด้วยการปรับแต่งระบบ)

เมื่อติดตั้ง LoadRunner เสร็จแล้ว เรามาทำความเข้าใจขั้นตอนต่างๆ ในกระบวนการนี้ทีละขั้นตอนกัน

แผนงานการทดสอบประสิทธิภาพ 5 ขั้นตอน ตั้งแต่การวางแผนจนถึงการวิเคราะห์ผลลัพธ์

ขั้นตอนที่ 1) การวางแผนสำหรับการทดสอบโหลด

การวางแผนการทดสอบประสิทธิภาพแตกต่างจากการวางแผนก SIT (การทดสอบการรวมระบบ) or UAT (การทดสอบการยอมรับของผู้ใช้)- การวางแผนสามารถแบ่งออกเป็นขั้นตอนย่อยๆ ได้ดังนี้

รวบรวมทีมของคุณ

เมื่อเริ่มต้นใช้งาน LoadRunner Testing ควรบันทึกว่าใครบ้างจากแต่ละทีมที่เกี่ยวข้องจะเข้าร่วมกิจกรรมนี้ ดังแผนผังทีมด้านล่าง

บทบาทต่างๆ ที่จัดเตรียมไว้สำหรับทีมทดสอบประสิทธิภาพ LoadRunner

  • ผู้จัดการโครงการ: เสนอชื่อผู้จัดการโครงการที่จะเป็นเจ้าของกิจกรรมนี้และทำหน้าที่เป็นผู้ชี้ประเด็นในการยกระดับปัญหา
  • ผู้เชี่ยวชาญด้านฟังก์ชัน / นักวิเคราะห์ธุรกิจ: ให้บริการวิเคราะห์การใช้งาน SUL และความเชี่ยวชาญด้านฟังก์ชันการทำงานทางธุรกิจของเว็บไซต์หรือ SUL
  • ผู้เชี่ยวชาญด้านการทดสอบประสิทธิภาพ: สร้างการทดสอบประสิทธิภาพอัตโนมัติและดำเนินการจำลองสถานการณ์การโหลด
  • System Archiเทค: จัดทำพิมพ์เขียวของ SUL
  • นักพัฒนาเว็บและ SME: ดูแลรักษาเว็บไซต์ ตรวจสอบการทำงาน พัฒนาเว็บไซต์ และแก้ไขข้อผิดพลาด
  • ผู้ดูแลระบบ: ดูแลรักษาเซิร์ฟเวอร์ที่เกี่ยวข้องตลอดโครงการทดสอบ

อธิบายภาพรวมของแอปพลิเคชันและกระบวนการทางธุรกิจที่เกี่ยวข้อง

ที่ประสบความสำเร็จ โหลดการทดสอบ ต้องการให้คุณวางแผนที่จะดำเนินกระบวนการทางธุรกิจบางอย่าง กระบวนการทางธุรกิจประกอบด้วยขั้นตอนที่กำหนดไว้อย่างชัดเจนเพื่อให้สอดคล้องกับธุรกรรมทางธุรกิจที่ต้องการ เพื่อให้บรรลุวัตถุประสงค์การทดสอบโหลดของคุณ

สามารถจัดเตรียมตัวชี้วัดข้อกำหนดเพื่อกระตุ้นโหลดของผู้ใช้บนระบบ ด้านล่างนี้เป็นตัวอย่างของระบบการเข้างานในบริษัท:

แผนผังตัวชี้วัดความต้องการping จำนวนผู้ใช้ต่อกระบวนการทางธุรกิจในแต่ละชั่วโมงของวัน

ในตัวอย่างข้างต้น ตัวเลขแสดงจำนวนผู้ใช้ที่เชื่อมต่อกับแอปพลิเคชัน (SUL) ในชั่วโมงที่กำหนด เราสามารถยกตัวอย่างได้ดังนี้tract คือจำนวนผู้ใช้สูงสุดที่เชื่อมต่อกับกระบวนการทางธุรกิจในแต่ละชั่วโมงของวัน ซึ่งคำนวณจากคอลัมน์ขวาสุด

ในทำนองเดียวกัน เราสามารถสรุปจำนวนผู้ใช้ทั้งหมดที่เชื่อมต่อกับแอปพลิเคชัน (SUL) ในเวลาใดก็ได้ของวัน ซึ่งคำนวณในแถวสุดท้าย

ข้อเท็จจริง 2 ประการข้างต้นรวมกันทำให้เราทราบจำนวนผู้ใช้ทั้งหมดที่เราต้องทดสอบระบบเพื่อประสิทธิภาพ

กำหนดขั้นตอนการจัดการข้อมูลการทดสอบ

สถิติและการสังเกตที่ได้จากการทดสอบประสิทธิภาพได้รับอิทธิพลอย่างมากจากปัจจัยหลายประการดังที่บรรยายไว้ก่อนหน้านี้ การเตรียมข้อมูลการทดสอบสำหรับการทดสอบประสิทธิภาพถือเป็นสิ่งสำคัญอย่างยิ่ง บางครั้ง กระบวนการทางธุรกิจหนึ่งๆ จะใช้ชุดข้อมูลและสร้างชุดข้อมูลอื่น ยกตัวอย่างด้านล่าง:

  • ผู้ใช้ 'A' สร้างบัญชีทางการเงินtracและส่งเพื่อตรวจสอบ
  • ผู้ใช้รายอื่นชื่อ 'B' อนุมัติ 200 คอนtracts เป็นวันที่สร้างโดยผู้ใช้ 'A'
  • ผู้ใช้รายอื่นชื่อ 'C' จ่ายประมาณ 150 เหรียญtracเป็นวันที่ผู้ใช้ 'B' อนุมัติแล้ว

ในสถานการณ์นี้ ผู้ใช้ B จำเป็นต้องมี 200 คอนtracts 'ถูกสร้างขึ้น' ในระบบ นอกจากนี้ ผู้ใช้ C ต้องการ 150 contracts ถูกตั้งค่าเป็น "อนุมัติ" เพื่อจำลองการใช้งานของผู้ใช้ 150 คน

โดยนัยแล้วหมายความว่าคุณต้องสร้างอย่างน้อย 200 + 150 = 350 ชิ้นtracทีเอส

หลังจากนั้น อนุมัติ 150 คอนtracts จะใช้เป็นข้อมูลทดสอบสำหรับผู้ใช้ C – ส่วนที่เหลืออีก 200 contracts จะใช้เป็นข้อมูลทดสอบสำหรับผู้ใช้ B

จอภาพโครงร่าง

พิจารณาปัจจัยทุกอย่างที่อาจส่งผลต่อประสิทธิภาพของระบบ ตัวอย่างเช่น การลดฮาร์ดแวร์อาจส่งผลกระทบต่อประสิทธิภาพ SUL (System Under Load) ได้

รวบรวมปัจจัยทั้งหมดและตั้งค่าจอภาพเพื่อให้คุณสามารถวัดได้ นี่เป็นตัวอย่างบางส่วน:

  • ตัวประมวลผล (สำหรับเว็บเซิร์ฟเวอร์ แอปพลิเคชันเซิร์ฟเวอร์ เซิร์ฟเวอร์ฐานข้อมูล และหัวฉีด)
  • RAM (สำหรับเว็บเซิร์ฟเวอร์, เซิร์ฟเวอร์แอปพลิเคชัน, เซิร์ฟเวอร์ฐานข้อมูล และหัวฉีด)
  • เซิร์ฟเวอร์เว็บ/แอป (เช่น IIS, JBoss, Jaguar Server, Tomcat ฯลฯ)
  • DB Server (ขนาด PGA และ SGA ในกรณีของ Oracle และเซิร์ฟเวอร์ MSSQL, SP เป็นต้น)
  • การใช้แบนด์วิธเครือข่าย
  • NIC ภายในและภายนอกในกรณีที่มีการคลัสเตอร์
  • Load Balancer (และกระจายโหลดอย่างเท่าเทียมกันบนโหนดทั้งหมดของคลัสเตอร์)
  • ข้อมูล flux (คำนวณปริมาณข้อมูลที่ส่งผ่านระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ จากนั้นคำนวณว่าความจุของ NIC เพียงพอที่จะจำลองผู้ใช้จำนวน X คนหรือไม่)

ขั้นตอนที่ 2) สร้างสคริปต์ VuGen

ขั้นตอนต่อไปหลังจากวางแผนคือการสร้างสคริปต์ VUser โดยเพิ่มส่วนต่างๆ เข้าไป การกำหนดค่าพารามิเตอร์ การทำธุรกรรม และการตั้งค่าขณะทำงาน เมื่อบทภาพยนตร์พัฒนาไปเรื่อยๆ

ขั้นตอนที่ 3) การสร้างสถานการณ์

ขั้นตอนต่อไปคือการสร้างสถานการณ์การโหลดของคุณในตัวควบคุม โดยเลือกระหว่างสถานการณ์แบบกำหนดเองหรือสถานการณ์แบบกำหนดเป้าหมาย

ขั้นตอนที่ 4) การดำเนินการตามสถานการณ์

การดำเนินการตามสถานการณ์จำลองคือการที่คุณเลียนแบบโหลดของผู้ใช้บนเซิร์ฟเวอร์โดยสั่งให้ VUser หลายรายดำเนินการพร้อมกัน

คุณสามารถกำหนดระดับการโหลดได้โดยการเพิ่มและลดจำนวน VUsers ที่ทำงานพร้อมกัน

การดำเนินการนี้อาจส่งผลให้เซิร์ฟเวอร์ล่มได้ ความเครียด และมีพฤติกรรมที่ผิดปกติ นี่คือจุดประสงค์หลักของการทดสอบประสิทธิภาพ ผลลัพธ์ที่ได้จะถูกนำไปใช้ในการวิเคราะห์อย่างละเอียดและการระบุสาเหตุที่แท้จริง

ขั้นตอนที่ 5) การวิเคราะห์ผลลัพธ์ (ตามด้วยการปรับแต่งระบบ)

ระหว่างการจำลองสถานการณ์ LoadRunner จะบันทึกประสิทธิภาพของแอปพลิเคชันภายใต้ภาระงานที่แตกต่างกัน สถิติที่ได้จากการทดสอบจะถูกบันทึกไว้ และจะมีการวิเคราะห์อย่างละเอียด เครื่องมือวิเคราะห์ (ซึ่งมีชื่อว่า 'HP Analysis' ในเวอร์ชันที่ใช้เขียนคู่มือนี้) จะสร้างกราฟต่างๆ ซึ่งช่วยในการระบุสาเหตุหลักที่ทำให้ระบบทำงานช้าลง รวมถึงความล้มเหลวของระบบด้วย

กราฟบางส่วนที่ได้รับได้แก่:

  • เวลาถึงบัฟเฟอร์แรก
  • เวลาตอบสนองธุรกรรม
  • เวลาตอบสนองธุรกรรมโดยเฉลี่ย
  • จำนวนการเข้าชมต่อวินาที
  • Windows แหล่งข้อมูล
  • สถิติข้อผิดพลาด
  • สรุปธุรกรรม

คำถามที่พบบ่อย

การทดสอบประสิทธิภาพมุ่งเป้าไปที่ระบบไคลเอ็นต์-เซิร์ฟเวอร์และผู้ใช้หลายคน เช่น โปรแกรมยูทิลิตี้แบบสแตนด์อโลนบนเดสก์ท็อป Microsoft เครื่องคิดเลขนี้ให้บริการแก่ผู้ใช้เพียงคนเดียวและไม่มีเซิร์ฟเวอร์ ดังนั้นจึงไม่เหมาะสำหรับการทดสอบประสิทธิภาพ

การทดสอบประสิทธิภาพจะวัดและรายงานว่าแอปพลิเคชันทำงานอย่างไรภายใต้ภาระงานหนัก วิศวกรรมประสิทธิภาพจะผสานการทดสอบนั้นเข้ากับการปรับแต่ง เพื่อให้ระบบได้รับการวัดและปรับให้เหมาะสมไปพร้อมกันจนกว่าจะได้ประสบการณ์การใช้งานที่ผู้ใช้ต้องการ

ลำดับ OpenText บริษัทได้ดำเนินการเข้าซื้อกิจการ Micro Focus เสร็จสิ้นในเดือนมกราคม 2023 และปัจจุบันธุรกิจของครอบครัวได้ถูกขายออกไปแล้ว OpenText วิศวกรรมประสิทธิภาพระดับมืออาชีพ ระดับองค์กร และระดับแกนหลัก

แพ็กเกจ Professional เหมาะสำหรับทีมเดียวที่ใช้งานบนเครื่องเดียว แพ็กเกจ Enterprise เพิ่มการทดสอบแบบใช้ร่วมกันตามโครงการทั่วทั้งองค์กร และแพ็กเกจ Core ทำงานสร้างโหลดบนระบบคลาวด์โดยไม่ต้องใช้ตัวสร้างโหลดในเครื่อง

นำจำนวน VUser เป้าหมายมาหารด้วยปริมาณหน่วยความจำที่โปรโตคอลนั้นใช้ ในตัวอย่าง HTTP ข้างต้น 2-4 MB ต่อ VUser หมายความว่าเครื่องขนาด 4 GB ประมาณสี่เครื่องจะรองรับ VUser ได้ 10,000 ราย

การปลอมแปลง IP ทำให้ VUser แต่ละตัวมีที่อยู่ต้นทางที่แตกต่างกัน ดังนั้นตัวกระจายโหลด แคช และเซิร์ฟเวอร์จึงมองว่าการรับส่งข้อมูลจำลองนั้นเป็นไคลเอนต์แยกกันหลายราย แทนที่จะเป็นเครื่องเดียวที่ใช้งานเต็มประสิทธิภาพ

การเรียนรู้ของเครื่องจะกำหนดเวลาตอบสนองปกติเป็นเกณฑ์มาตรฐาน ตรวจจับการทำงานที่ผิดปกติโดยอัตโนมัติ และจัดกลุ่มข้อผิดพลาดที่เกี่ยวข้อง ทำให้วิศวกรใช้เวลาน้อยลงในการอ่านกราฟและใช้เวลามากขึ้นในการแก้ไขปัญหาคอขวดที่ต้นเหตุ

Copilot สคริปต์นี้สร้างโค้ดตัวช่วยและตรรกะการกำหนดพารามิเตอร์ในรูปแบบภาษา C สำหรับ VuGen แต่ไม่สามารถทราบค่าความสัมพันธ์ที่คุณบันทึกไว้ได้ ดังนั้นสคริปต์ที่สร้างขึ้นทุกสคริปต์จึงยังคงต้องมีการตรวจสอบการเล่นซ้ำอยู่ดี

สรุปโพสต์นี้ด้วย: