บริการทดสอบโหลด บริการโหลดทดสอบ loadme
ทีมงานของเราเผชิญกับข้อบกพร่องของเครื่องมือทดสอบโหลด และในที่สุดก็ตัดสินใจพัฒนาบริการของเราเอง ปัญหาหลัก:
- หากเป็นบริการ ราคาก็สูงเกินไปสำหรับภาระงานร้ายแรง
- หากเป็นยูทิลิตี้ ผลลัพธ์จะขึ้นอยู่กับความเร็วของช่องคอมพิวเตอร์/เซิร์ฟเวอร์ที่ใช้ทำการทดสอบ
- การสืบค้นซ้ำๆ ไม่ได้สะท้อนถึงความเร็วที่แท้จริง เนื่องจากการแคชเกิดขึ้นในระดับต่างๆ ตั้งแต่ CPU จนถึงฐานข้อมูล
มีอะไรทำไปแล้วบ้าง?
- คุณสามารถทดสอบงานจากรายการ URL ได้สูงสุด 20 ชิ้น
- แต่ละ URL สามารถมีพารามิเตอร์สุ่มได้ตั้งแต่หนึ่งพารามิเตอร์ที่ระบุโดยใช้ฟังก์ชัน $RND
- การทดสอบดำเนินการจากเซิร์ฟเวอร์หลายเครื่อง โดยแต่ละเซิร์ฟเวอร์ทำงานเพียง 8 เธรดเท่านั้น
- การทดสอบสามารถทำได้จาก 5 ภูมิภาค AWS - ดับลิน แฟรงก์เฟิร์ต สหรัฐอเมริกาตะวันออก/ตะวันตก โตเกียว
- เราพร้อมที่จะให้การทดสอบมากถึง 200 เธรดฟรี
*** อัปเดต ***
ฉันเห็นชาวเมืองคาบราผู้กล้าหาญจำนวนมากตั้งภารกิจ 200 กระทู้ หากเราสมมติว่ามีการแสดงผล 1 เพจใน 1 วินาที สิ่งนี้จะสอดคล้องกับปริมาณการเข้าชม > 100,000 ผู้เข้าชมต่อชั่วโมง โครงการทั่วไป รวมถึงของเรา เสียชีวิตจากการทดสอบดังกล่าว
ในอีกสักครู่ ผลลัพธ์ของคุณก็จะพร้อม (ดูตัวอย่าง ดูผลลัพธ์ที่ยอดเยี่ยม - การทดสอบ example.net) อย่างที่คุณเห็น 200 เธรดช่วยให้คุณสร้างคำขอมากกว่า 1,000 รายการต่อวินาที - ทั้งหมดขึ้นอยู่กับความเร็วของการสื่อสารกับบริการที่กำลังทดสอบ ฯลฯ ที่จริงแล้วคือความเร็วของการตอบสนอง
หากคุณพร้อมที่จะแสดงผลลัพธ์ของคุณบนเว็บไซต์ของเรา คุณสามารถคลิกปุ่มผลลัพธ์สาธารณะได้ หากต้องการแสดงให้เพื่อนร่วมงานเห็น เพียงส่งลิงก์
จะทดสอบอะไร?
ทรัพยากรแบบคงที่ รูปภาพ สคริปต์จะต้องให้บริการจาก CDN มันไม่สมเหตุสมผลเลยที่จะทดสอบความเร็วในการอัพโหลด IMHO คุณแค่ต้องทดสอบความเร็วในการโหลดหน้าโดยรวมเท่านั้น เช่น ใช้ http://tools.pingdom.com/fpt/
Loadme มุ่งเน้นไปที่การทดสอบโค้ดเพจ / วิธี api ฯลฯ ... แน่นอนว่าเป็นไปได้ที่จะทดสอบ nginx ที่ให้บริการ 1x1.gif โดยใช้เครื่องมือนี้ แต่ไม่มีผลประโยชน์ในทางปฏิบัติและ nginx จะไม่อุ่นเครื่องจากสิ่งนี้ด้วยซ้ำ
หากต้องการทราบว่าหน้าใดเป็นจุดคอขวด ควรใช้ newrelic ต่างจากการวิเคราะห์ของ Google ยอดนิยมตรงที่ยังช่วยให้คุณติดตามสถิติคำขอของบอท และสร้างแบบสอบถามตามจำนวนการดำเนินการต่อหน้า รวมถึงหน้าใดที่ทำให้ประสบการณ์ผู้ใช้เสียมากที่สุดตามดัชนี apdex
ดังที่คุณทราบ แมลงวันในครีมจะทำให้น้ำผึ้งเสียหนึ่งถัง และหากแอปพลิเคชันของคุณช้าลงในการกระทำบางอย่างที่ค่อนข้างหายาก สิ่งนี้อาจส่งผลต่อการทำงานแบบมีน้ำหนักเบายอดนิยม
การเปลี่ยนเส้นทางทำงานอย่างไร
การเปลี่ยนเส้นทางจะดำเนินการ เราใช้สิ่งเหล่านี้เพื่อทดสอบหนึ่งในเว็บไซต์ wikiart.org ของเรา โดยใช้ฟังก์ชัน "ไปที่รูปภาพสุ่ม"
เหตุใดการทดสอบหลาย URL จึงสำคัญ
เพื่อทดสอบอิทธิพลร่วมกันของหน้าที่เร็วและหน้าที่ช้ายอดนิยม (เช่น การค้นหา)
เหตุใดจึงต้องใช้ $RND?
ไวยากรณ์คือ $RND(from,to)
ตัวอย่างเช่น http://someshop.com/search?from=$RND(0,1000)&to=$RND(1000,10000) จะสร้างข้อความค้นหาที่กำหนดเองเพื่อค้นหาผลิตภัณฑ์ที่มีราคาตั้งแต่ 0 ถึง 1,000 และลงท้ายด้วย 1,000 ถึง 10,000 ทำให้สามารถประมาณกำลังการค้นหาที่แท้จริงได้
ตัวอย่างเช่น Rozetka ร้านค้าชื่อดังในยูเครนใช้เวลาเฉลี่ย 5 วินาทีในการค้นหาสมาร์ทโฟนในราคาสุ่ม:
http://loadme.socialtalents.com/Result/ViewById/56108a645b5f1700481cc21d ซึ่งยังห่างไกลจากผลลัพธ์ในอุดมคติมาก
Amazon รับมือกับงานนี้ได้ดีขึ้นโดยพื้นฐาน - ข้อผิดพลาดจำนวนมากซึ่งส่งผลให้มีการป้องกัน ddos มากที่สุด
แผนการในอนาคต
โพสต์ ใส่ ลบ คำขอ
สิ่งสำคัญอยู่ในแผนอย่างแน่นอน
การอนุญาต
การสนับสนุนคุกกี้จะเพียงพอหรือไม่เพื่อให้คำขอแรกบันทึกการทดสอบภายใต้ผู้ใช้แบบสุ่ม (ซึ่งจะต้องได้รับการสนับสนุนจากเซิร์ฟเวอร์) และการทำงานเพิ่มเติมจะเกิดขึ้นในนามของผู้ใช้รายนี้หรือไม่
การทดสอบขั้นตอน
สมมติว่าทำการทดสอบหลายชุด: 25%, 50%, 75% และ 100% แล้วดูความแตกต่างของความเร็ว
แทนที่จะเลือกจำนวนเธรด ให้ผู้ใช้เลือกจำนวนการดำเนินการต่อวินาทีที่เขาต้องการเริ่มต้น
การทดสอบตามกำหนดเวลาปกติ
ทำซ้ำการทดสอบทุกวัน/สัปดาห์ และส่งรายงานทางอีเมล
คุณยังจัดเตรียมเว็บฮุคบางประเภทเพื่อทริกเกอร์การทดสอบที่มีอยู่จากโค้ดได้ (เช่น หลังการอัปเดต)
ปรับปรุงการแสดงภาพปริมาณงาน
เซิร์ฟเวอร์อาจมีพฤติกรรมผิดปกติ เราวางแผนที่จะเพิ่มการแสดงภาพปริมาณงานของเซิร์ฟเวอร์เป็นวินาที
การยืนยันความเป็นเจ้าของโดเมน
มีการจำกัดตัวแทนไม่เกิน 200 รายต่อโดเมนเพื่อให้แน่ใจว่าจะไม่มีใครโยนเว็บไซต์ของผู้อื่นเข้าสู่ ddos คุณสามารถสร้างโดเมนย่อยอื่นสำหรับไซต์ของคุณและทดสอบอีกครั้งได้
อย่างไรก็ตาม ในอนาคต จำเป็นต้องยืนยันโดเมนโดยใช้ระเบียน CNAME หรือไฟล์ที่มีชื่อเฉพาะ
คู่แข่งที่มีอยู่
Loadimpact.com - สำหรับการทดสอบการโหลดปกติ จะต้องมีคำขออย่างน้อย 100 รายการต่อวินาที โดยจะต้องมี 1,500 รายการที่เรียกว่า “ผู้ใช้เสมือน” โดยแต่ละรายการจะโหลดหน้าเว็บทุกๆ 15 วินาที แพ็คเกจนี้ปัจจุบันมีราคา $ 299 ต่อเดือนLoader.io เป็นบริการที่ยอดเยี่ยม แพ็คเกจแบบชำระเงินเพียง $99 ต่อเดือน การตั้งค่า URL ที่ยืดหยุ่นมาก - คุณสามารถตั้งค่าวิธีการ คุกกี้ ส่วนหัวได้ แต่เราไม่มีการสุ่มการทดสอบเพียงพอ
เราดำเนินการต่อชุดบทความสำหรับผู้ทดสอบมือใหม่ ครั้งสุดท้ายที่ฉันบอกคุณว่าฉันเรียนอย่างไร คราวนี้ผมอยากจะพูดถึงภาระ การทดสอบความเครียดนี่เป็นการทดสอบประเภทที่ค่อนข้างซับซ้อนและน่าสนใจ แต่ต้องใช้เวลามากขึ้นและไม่ยอมให้มีข้อผิดพลาด
การทดสอบความเครียด
การทดสอบประเภทนี้ดำเนินการเพื่อประเมินความเสถียรของรหัสผลิตภัณฑ์และแพลตฟอร์ม โดยปกติจะได้รับการตรวจสอบโดยการมีข้อมูลและผู้ใช้จำนวนมาก การทดสอบโหลดไม่ค่อยให้คำตอบที่ชัดเจน ต่างจากการทดสอบเชิงฟังก์ชัน แต่เพียงระบุทิศทางที่ควรปรับปรุงผลิตภัณฑ์เท่านั้น เนื่องจากสามารถเพิ่มโหลดได้ไม่จำกัด จึงไม่มีโค้ดหรือเซิร์ฟเวอร์ใดที่สามารถทนต่อแรงกดดันดังกล่าวได้ แต่สิ่งสำคัญคือคุณต้องค้นหาว่าสามารถทำงานได้เต็มที่ภายใต้แรงกดดันใด
หากคุณลองดู คุณจะเห็นว่าการทดสอบประเภทนี้หมายถึงการทดสอบที่เน้นลูกค้าเป็นหลัก ซึ่งหมายความว่าการทดสอบโหลดมักจะดำเนินการกับผลิตภัณฑ์สำเร็จรูปและในสภาพแวดล้อมของผลิตภัณฑ์หรือผลิตภัณฑ์ โดยไม่ต้องเจาะลึกเข้าไปในโค้ด บ่อยครั้งในทางปฏิบัติของฉัน ด้วยความช่วยเหลือของการทดสอบโหลด ฉันจำเป็นต้องพิจารณาว่าโค้ดที่เขียนนั้นต้องการประสิทธิภาพการทำงานของเซิร์ฟเวอร์มากน้อยเพียงใด
เจมิเตอร์
เช่นเดียวกับการทดสอบอัตโนมัติ การทดสอบโหลดจะต้องเรียนรู้โดยตรงในทางปฏิบัติ เบาะแสเดียวคือ Jmeter เนื่องจากต่อมากลายเป็นหนึ่งในเครื่องมือที่มีชื่อเสียงที่สุดสำหรับการทดสอบโหลด ข้อดีที่สำคัญของ Jmeter คือมีชุมชนขนาดใหญ่ เป็นโอเพ่นซอร์สและมีการอัปเดตค่อนข้างบ่อย โปรแกรมยังมี GUI ที่เป็นมิตรต่อผู้ใช้และสามารถเปิดใช้งานผ่านคอนโซลได้
ค้นหา: jmeter, การทดสอบโหลดด้วย jmeter
มีบทช่วยสอนที่ยอดเยี่ยมหลายประการเกี่ยวกับHabréเกี่ยวกับการสร้างการทดสอบโหลด ซึ่งเป็นสิ่งที่ฉันได้รับคำแนะนำขณะศึกษาเครื่องมือนี้
จนถึงตอนนี้ ฉันยังไม่เชี่ยวชาญฟีเจอร์ทั้งหมดของ Jmeter ได้อย่างเต็มที่ เนื่องจากมีฟังก์ชันมากมาย แต่ฉันเชี่ยวชาญงานพื้นฐานของการสร้างสถานการณ์ทดสอบสำหรับโหลดได้ ในขณะที่ทำงานกับ jmeter ผู้ที่ไม่คุ้นเคยกับการทดสอบโหลดจะมีคำถามมากมายเกี่ยวกับคำศัพท์ใหม่ นอกจากนี้ยังอำนวยความสะดวกด้วยอินเทอร์เฟซภาษาอังกฤษ จดชื่อที่ไม่ชัดเจนและอย่าลืมศึกษาในขณะที่คุณไป ตัวอย่างเช่น สำหรับฉันมันคือเธรดและการสลับ
ค้นหา: เธรด, สลับ
ตัวแปรของงานที่น่าสนใจสำหรับการทดสอบโหลด คุณต้องตรวจสอบว่าเว็บแอปพลิเคชันสามารถรองรับผู้ใช้ออนไลน์ได้ 200 ร้อยรายที่จะมีส่วนร่วมในการโต้ตอบในการแชทในตัว มีตัวเลือกที่เป็นไปได้มากมายสำหรับงานดังกล่าวที่คุณสามารถตัดสินใจเขียนเองได้ กำหนดงานให้กับตัวเองในบางโปรเจ็กต์ของคุณเอง (เพื่อไม่ให้คนอื่นทำลาย) และเริ่มแก้ไขปัญหาโดยใช้ jmeter
หลังจากศึกษาคุณสมบัติมาตรฐานของ Jmeter แล้ว ฉันก็รู้สึกแย่ครั้งหนึ่ง ฉันตัดสินตัวชี้วัดที่รวบรวมไว้ผิดโดยสิ้นเชิงและได้รับการตำหนิจากเพื่อนร่วมงานอาวุโส จากนี้ผมสรุปได้ว่าการทดสอบโหลดเพียงรู้แค่เครื่องมือยังไม่เพียงพอ เป็นสิ่งสำคัญมากที่จะต้องประเมินตัวชี้วัดที่รวบรวมไว้อย่างถูกต้องหลังการทดสอบโหลด และได้ข้อสรุปที่ถูกต้องตามการวัดเหล่านั้น
ขอย้ำอีกครั้งว่า Jmeter เป็นเครื่องมือที่ทรงพลังและเป็นที่นิยมสำหรับการโหลด ฉันจะให้ความสำคัญกับเรื่องนี้เป็นอย่างมากเมื่อศึกษาการทดสอบประเภทนี้
มีเครื่องมืออื่นๆ สองสามอย่างที่ฉันเพิ่งเจอในการเขียนการทดสอบโหลดที่ฉันพบว่าน่าสนใจ
รถถังยานเดกซ์
ฉันไม่สามารถพูดได้อย่างมั่นใจ แต่ดูเหมือนว่านี่เป็นเครื่องมือที่ค่อนข้างเป็นที่รู้จักสำหรับการทดสอบโหลด ฉันใช้มันสองสามครั้งเพื่อเลียนแบบผู้ใช้จำนวนมากและ Yandex Tank ก็ทำงานได้ดีมากกับงานนี้ บางทีมันอาจจะเป็นทางเลือกแทน Jmeter สำหรับบางคนเนื่องจากใช้งานง่ายกว่า
ค้นหา: การทดสอบการโหลดถังยานเดกซ์
แนวทางที่ยอดเยี่ยมสำหรับการทดสอบโหลด แทนที่จะบันทึกสคริปต์จากบันทึก คุณสร้างสคริปต์ด้วยตนเองในโค้ด Python เว็บอินเตอร์เฟสในตัวช่วยให้คุณกำหนดค่าโหลดและเริ่มการตรวจสอบได้อย่างรวดเร็ว โซลูชันที่น่าสนใจมากและสามารถปรับขยายได้ดีด้วย Python
ค้นหา: ตั๊กแตน, ตั๊กแตนทดสอบโหลด
รปภ. มีบริการออนไลน์ที่น่าสนใจมากมายสำหรับการทดสอบโหลด ตัวอย่างเช่น loadimpact.com แน่นอนว่ามีการทดสอบโหลดขนาดใหญ่ แต่ในกรณีใด ๆ คุณสามารถลองใช้โหมดทดลองได้
นอกจากนี้ ขึ้นอยู่กับเทคโนโลยีที่ใช้ในการพัฒนา เครื่องมืออื่นๆ สามารถใช้ในการโหลดได้ ตัวอย่างเช่น SOAP UI จะช่วยให้คุณสามารถโหลดพร้อมกับคำขอได้ โดยทั่วไปแล้ว SOAP UI มีประโยชน์มากมาย ฉันแนะนำให้อ่านหรือลองใช้ในยามว่าง
การทดสอบประเภทนี้จะแตกต่างออกไปเล็กน้อย แต่มีเป้าหมายที่คล้ายกัน - เพื่อปรับปรุงคุณภาพและความเสถียรของผลิตภัณฑ์และแพลตฟอร์มของคุณ
บ่อยครั้งที่มีการทดสอบประสิทธิภาพเมื่อปัญหาด้านประสิทธิภาพแสดงออกมาแล้ว นี่เป็นกรณีของฉัน
สถานการณ์ที่เกิดซ้ำบ่อยครั้ง
- ฟังก์ชันหนึ่งที่โชคร้ายกินทรัพยากรส่วนใหญ่และทำให้ผลิตภัณฑ์ทั้งหมดช้าลง
- การใช้ทรัพยากรที่มีอยู่อย่างระมัดระวังเกินไป แม้ว่าโค้ดจะสามารถทำงานได้เร็วขึ้นหลายเท่าก็ตาม
หากต้องการค้นหาปัญหาดังกล่าว คุณต้องมีสิทธิ์เข้าถึงโค้ด ฐานข้อมูล คอนโซลเซิร์ฟเวอร์ และเข้าใจอย่างชัดเจนถึงสิ่งที่เกิดขึ้น ความสามารถในการทำงานกับบรรทัดคำสั่งโดยทั่วไปมีความเหมาะสมมากที่นี่
สะดวกมากสำหรับการตรวจสอบสถานการณ์ข้างต้น ผู้สร้างโปรไฟล์รหัส- เมื่อใช้ตัวสร้างโปรไฟล์ คุณสามารถกำหนดได้ว่าโค้ดแต่ละชิ้นจะใช้เวลานานเท่าใด บ่อยครั้งที่นักพัฒนาทำเช่นนี้ แต่ฉันคิดว่ามันจะไม่ส่งผลเสียต่อผู้ทดสอบเช่นกัน คุณสามารถค้นหาข้อผิดพลาดที่ชัดเจนและทำการเปลี่ยนแปลงที่เหมาะสมได้
ค้นหา: ผู้สร้างโปรไฟล์โค้ด
ระบบการตรวจสอบยังมีประโยชน์มากที่นี่ ตัวอย่างเช่น Zabbix, Ansible และอื่นๆ ด้วยความช่วยเหลือเหล่านี้ คุณสามารถติดตามทรัพยากรที่ใช้โดยสคริปต์บางตัวและสร้างรายงานระยะยาวได้ ระบบเหล่านี้ใช้งานโดยทีมงาน dev-ops เป็นหลัก แต่ก็จะช่วยอย่างมากในการทดสอบเช่นกัน
นั่นคือทั้งหมดที่ ฉันหวังว่าฉันจะแสดงวิธีขุดและวิธีปฏิบัติ ฉันยินดีที่จะได้ยินคำถามของคุณในความคิดเห็น
การทดสอบความเครียด
การทดสอบความเครียด(ภาษาอังกฤษ) การทดสอบโหลด) - การกำหนดหรือการรวบรวมตัวบ่งชี้ประสิทธิภาพและเวลาตอบสนองของระบบซอฟต์แวร์และฮาร์ดแวร์หรืออุปกรณ์เพื่อตอบสนองต่อคำขอภายนอกเพื่อสร้างการปฏิบัติตามข้อกำหนดสำหรับระบบที่กำหนด (อุปกรณ์)
เพื่อศึกษาเวลาตอบสนองของระบบที่โหลดสูงหรือพีค จะทำการทดสอบความเครียด ซึ่งโหลดที่สร้างขึ้นบนระบบจะเกินกว่าสถานการณ์ปกติของการใช้งาน ไม่มีขอบเขตที่ชัดเจนระหว่างการทดสอบโหลดและการทดสอบภาวะวิกฤต แต่ไม่ควรสับสนแนวคิดเหล่านี้ เนื่องจากการทดสอบประเภทนี้จะตอบคำถามทางธุรกิจที่แตกต่างกันและใช้วิธีการที่แตกต่างกัน
การทดสอบการโหลดซอฟต์แวร์
ภาคเรียน การทดสอบความเครียดสามารถใช้ได้ในความหมายต่าง ๆ ในสภาพแวดล้อมการทดสอบซอฟต์แวร์ระดับมืออาชีพ โดยทั่วไปหมายถึงการฝึกจำลองการใช้งานแอปพลิเคชันที่คาดหวังโดยการจำลองผู้ใช้หลายรายในเวลาเดียวกัน ดังนั้นการทดสอบดังกล่าวจึงเหมาะสมที่สุดสำหรับระบบที่มีผู้ใช้หลายราย โดยส่วนใหญ่มักใช้สถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์ (เช่น เว็บเซิร์ฟเวอร์) อย่างไรก็ตาม ระบบซอฟต์แวร์ประเภทอื่นๆ ก็สามารถทดสอบได้ในลักษณะเดียวกัน ตัวอย่างเช่น โปรแกรมแก้ไขข้อความหรือกราฟิกสามารถจัดทำขึ้นเพื่ออ่านเอกสารขนาดใหญ่มากได้ และแพ็คเกจทางการเงิน - สร้างรายงานตามข้อมูลเป็นเวลาหลายปี การทดสอบโหลดที่ออกแบบมาอย่างเหมาะสมที่สุดจะให้ผลลัพธ์ที่แม่นยำยิ่งขึ้น
เป้าหมายหลักของการทดสอบโหลดคือการสร้างโหลดบางอย่างที่คาดหวังไว้บนระบบ (เช่น ผ่านผู้ใช้เสมือน) และโดยปกติจะใช้ซอฟต์แวร์และฮาร์ดแวร์ที่เหมือนกันเพื่อสังเกตประสิทธิภาพของระบบ
| ตัวอย่างที่ 1:
บริการเว็บที่มีฟังก์ชันตะกร้าสินค้าได้รับการออกแบบมาสำหรับผู้ใช้พร้อมกัน 100 รายที่ติดตามสถานการณ์บางอย่าง (การดำเนินการที่ระบุในสัดส่วนที่ระบุ):
ในกรณีนี้ การทดสอบโหลดควรจำลองสถานการณ์ทั่วไปของการทำงานกับบริการเว็บที่อธิบายไว้ข้างต้น เพื่อให้แน่ใจว่าระบบพร้อมที่จะเข้าสู่การใช้งานจริง ในกรณีนี้ สามารถใช้ตัวบ่งชี้ประสิทธิภาพของระบบโดยรวมหรือแต่ละโหนดของระบบเพื่อการวิเคราะห์โดยเฉพาะได้ |
ตามหลักการแล้ว เกณฑ์สำหรับความสำเร็จของการทดสอบโหลดคือข้อกำหนดด้านประสิทธิภาพของระบบ ซึ่งได้รับการกำหนดสูตรและจัดทำเป็นเอกสารในขั้นตอนของการพัฒนาข้อกำหนดด้านการทำงานสำหรับระบบ ก่อนที่จะเขียนโปรแกรมโซลูชันทางสถาปัตยกรรมหลัก อย่างไรก็ตาม มักเกิดขึ้นว่าข้อกำหนดดังกล่าวไม่ได้กำหนดไว้อย่างชัดเจนหรือไม่ได้กำหนดไว้เลย ในกรณีนี้ การทดสอบโหลดครั้งแรกจะเป็น การทดลอง (การทดสอบโหลดเชิงสำรวจ) และตั้งอยู่บนสมมติฐานที่สมเหตุสมผลเกี่ยวกับปริมาณงานและการใช้ทรัพยากรที่คาดหวังของฮาร์ดแวร์
หนึ่งในแนวทางที่ดีที่สุดในการใช้การทดสอบโหลดเพื่อวัดประสิทธิภาพของระบบคือการทดสอบในช่วงเริ่มต้นของการพัฒนา การทดสอบโหลดในขั้นตอนแรกของความพร้อมของโซลูชันสถาปัตยกรรม เพื่อตรวจสอบความมีชีวิตเรียกว่าการทดสอบ "Proof-of-Concept"
หลักการพื้นฐานของการทดสอบโหลด
ด้านล่างนี้คือข้อเท็จจริงเชิงทดลองบางส่วน ซึ่งสรุปเป็นหลักการที่ใช้ในการทดสอบประสิทธิภาพโดยทั่วไปและใช้ได้กับการทดสอบประสิทธิภาพทุกประเภท (โดยเฉพาะการทดสอบโหลด)
1. ความเป็นเอกลักษณ์ของคำขอแม้ว่าจะได้สร้างสถานการณ์จำลองที่สมจริงสำหรับการทำงานกับระบบตามสถิติการใช้งานแล้ว คุณยังต้องเข้าใจว่าจะมีข้อยกเว้นสำหรับสถานการณ์นี้เสมอ
ภาพประกอบของการแจกแจงการกระจายที่แตกต่างกันสำหรับเวลาดำเนินการของแบบสอบถาม X และ Y
เมื่อไร ตัวอย่างที่ 1นี่อาจเป็นผู้ใช้ที่เข้าถึงเพจเฉพาะของบริการเว็บที่แตกต่างจากบริการอื่นๆ ทั้งหมด
2. เวลาตอบสนองของระบบโดยทั่วไป เวลาตอบสนองของระบบจะเป็นไปตามฟังก์ชันการแจกแจงแบบปกติ
โดยเฉพาะอย่างยิ่ง นี่หมายความว่าการมีการวัดจำนวนเพียงพอ คุณสามารถกำหนดความน่าจะเป็นที่ระบบจะตอบสนองต่อคำขอภายในช่วงเวลาที่กำหนดได้
3. การขึ้นอยู่กับเวลาตอบสนองของระบบกับระดับการกระจายตัวของระบบนี้ความแปรปรวนของการกระจายปกติของเวลาตอบสนองของระบบต่อคำขอจะเป็นสัดส่วนกับอัตราส่วนของจำนวนโหนดของระบบที่ประมวลผลคำขอดังกล่าวแบบขนานและจำนวนคำขอต่อโหนด
นั่นคือ การแพร่กระจายของเวลาตอบสนองของระบบได้รับอิทธิพลพร้อมกันจากจำนวนคำขอต่อโหนดของระบบและจำนวนโหนดเอง ซึ่งแต่ละจำนวนจะเพิ่มความล่าช้าแบบสุ่มเมื่อประมวลผลคำขอ
4. ความแปรผันของเวลาตอบสนองของระบบจากข้อความที่ 1, 2 และ 3 เราสามารถสรุปได้ว่าด้วยการวัดเวลาประมวลผลคำขอจำนวนมากเพียงพอ ในระบบใดก็ตาม จะต้องมีคำขอที่มีเวลาประมวลผลเกินค่าสูงสุดที่กำหนดไว้ในข้อกำหนดเสมอ ยิ่งไปกว่านั้น ยิ่งเวลารวมของการทดสอบนานขึ้น ค่าสูงสุดใหม่ก็จะยิ่งสูงขึ้นตามไปด้วย
ข้อเท็จจริงนี้จะต้องนำมาพิจารณาเมื่อสร้างข้อกำหนดด้านประสิทธิภาพของระบบตลอดจนเมื่อทำการทดสอบโหลดตามปกติ
5. โหลดความแม่นยำในการสร้างโปรไฟล์ความแม่นยำที่ต้องการในการสร้างโปรไฟล์โหลดซ้ำจะมีราคาแพงมากขึ้นเมื่อมีส่วนประกอบในระบบมากขึ้น
มักจะเป็นไปไม่ได้ที่จะพิจารณาทุกแง่มุมของโปรไฟล์โหลดสำหรับระบบที่ซับซ้อน เนื่องจากยิ่งระบบซับซ้อนมากขึ้นเท่าไร เวลาก็จะยิ่งมากขึ้นในการออกแบบ เขียนโปรแกรม และบำรุงรักษาโปรไฟล์โหลดที่เพียงพอสำหรับระบบ ซึ่งไม่จำเป็นเสมอไป แนวทางที่เหมาะสมที่สุดในกรณีนี้คือการสร้างสมดุลระหว่างต้นทุนในการพัฒนาการทดสอบและความครอบคลุมของฟังก์ชันการทำงานของระบบ ซึ่งส่งผลให้เกิดสมมติฐานเกี่ยวกับผลกระทบต่อประสิทธิภาพโดยรวมของส่วนใดส่วนหนึ่งของระบบที่อยู่ระหว่างการทดสอบ
ชุดเครื่องมือทดสอบประสิทธิภาพ
ควรสังเกตว่าการทดสอบประสิทธิภาพส่วนใหญ่ใช้เครื่องมือเดียวกันกับที่สามารถทำงานทั่วไปได้
มีความเข้าใจผิดทั่วไปว่าเครื่องมือทดสอบโหลดของระบบเป็นเครื่องมือบันทึกและเล่น เช่น เครื่องมืออัตโนมัติการทดสอบการถดถอย เครื่องมือทดสอบโหลดทำงานที่ระดับโปรโตคอล ในขณะที่เครื่องมือทดสอบการถดถอยอัตโนมัติทำงานที่ระดับออบเจ็กต์ GUI
มีเครื่องมือต่างๆ สำหรับการตรวจจับและตรวจสอบปัญหาในส่วนต่างๆ ของระบบ โหนดระบบทั้งหมดสามารถจำแนกได้ดังนี้:
- แอปพลิเคชัน,
- ฐานข้อมูล
- สุทธิ,
- การประมวลผลฝั่งไคลเอ็นต์
- โหลดบาลานซ์
ที่น่าสังเกตอีกประการหนึ่งคือการเกิดขึ้นของแอปพลิเคชัน Business-to-business (B2B) บนเครือข่ายที่ใช้ข้อตกลงระดับการให้บริการ (หรือ SLA, ข้อตกลงระดับการให้บริการ) ความนิยมที่เพิ่มขึ้นของแอปพลิเคชัน B2B ทำให้แอปพลิเคชันจำนวนมากขึ้นเรื่อยๆ เปลี่ยนไปใช้สถาปัตยกรรมเชิงบริการ ซึ่งมีการแลกเปลี่ยนข้อมูลโดยไม่ต้องมีส่วนร่วมของเว็บเบราว์เซอร์ ตัวอย่างของการโต้ตอบดังกล่าว ได้แก่ ตัวแทนการท่องเที่ยวขอข้อมูลเกี่ยวกับเที่ยวบินเฉพาะระหว่างเซนต์ปีเตอร์สเบิร์กและออมสค์ ในขณะที่สายการบินจำเป็นต้องตอบกลับภายใน 5 วินาที การละเมิดข้อตกลง SLA มักส่งผลให้ต้องเสียค่าปรับจำนวนมาก
เครื่องมือทดสอบโหลดที่ได้รับความนิยมสูงสุดมีดังต่อไปนี้
| โดย | ชื่อผู้ผลิต | ความคิดเห็น |
|---|---|---|
| เปิดSTA | “สถาปัตยกรรมการทดสอบระบบเปิด” | ซอฟต์แวร์ฟรีสำหรับการทดสอบโหลด/ความเครียด ได้รับอนุญาตภายใต้ GNU GPL ใช้สถาปัตยกรรมแอปพลิเคชันแบบกระจายตาม CORBA มีเวอร์ชัน Windows แม้ว่าจะมีปัญหาความเข้ากันได้กับ Windows Vista ก็ตาม การสนับสนุนสิ้นสุดลงในปี 2550 |
| เครื่องทดสอบประสิทธิภาพเชิงเหตุผลของ IBM | ไอบีเอ็ม | ซอฟต์แวร์ที่ใช้สภาพแวดล้อมการพัฒนา Eclipse ซึ่งช่วยให้คุณสามารถสร้างโหลดจำนวนมากและวัดเวลาตอบสนองสำหรับแอปพลิเคชันที่มีสถาปัตยกรรมไคลเอ็นต์-เซิร์ฟเวอร์ ต้องมีใบอนุญาต |
| เจมีเตอร์ | โครงการโอเพ่นซอร์ส Apache Jakarta | ชุดเครื่องมือข้ามแพลตฟอร์มที่ใช้ Java ซึ่งช่วยให้คุณทำการทดสอบโหลดโดยใช้การเชื่อมต่อ JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP ทำให้สามารถสร้างคำขอจำนวนมากจากคอมพิวเตอร์เครื่องต่างๆ และควบคุมกระบวนการจากเครื่องใดเครื่องหนึ่งได้ |
| HP LoadRunner | เอชพี | เครื่องมือทดสอบโหลดที่เดิมออกแบบมาเพื่อจำลองการทำงานของผู้ใช้พร้อมกันจำนวนมาก นอกจากนี้ยังใช้สำหรับการทดสอบหน่วยหรือการรวมระบบอีกด้วย |
| ซิลค์เพอร์ฟอร์เมอร์ | ไมโครโฟกัส | |
| การทดสอบโหลด Visual Studio | ไมโครซอฟต์ | Visual Studio มีเครื่องมือทดสอบประสิทธิภาพรวมถึงการทดสอบโหลด/หน่วย |
| โหลดเสร็จสมบูรณ์ | สมาร์ทแบร์ |
ตัวบ่งชี้ประสิทธิภาพหลัก (เมตริก)
ผลลัพธ์อย่างหนึ่งที่ได้รับระหว่างการทดสอบโหลดและใช้สำหรับการวิเคราะห์เพิ่มเติมคือตัวบ่งชี้ประสิทธิภาพของแอปพลิเคชัน ประเด็นหลักจะกล่าวถึงด้านล่าง
1. การใช้ทรัพยากร CPU (CPU, %)ตัวชี้วัดที่แสดงระยะเวลาที่ตัวประมวลผลใช้ไปจากช่วงเวลาที่กำหนดในการคำนวณสำหรับกระบวนการที่เลือก ในระบบสมัยใหม่ ปัจจัยสำคัญคือความสามารถของกระบวนการในการทำงานในหลายเธรด เพื่อให้โปรเซสเซอร์สามารถคำนวณแบบขนานได้ การวิเคราะห์ประวัติการใช้ทรัพยากรโปรเซสเซอร์สามารถอธิบายผลกระทบต่อประสิทธิภาพโดยรวมของระบบของโฟลว์ข้อมูลที่ประมวลผล การกำหนดค่าแอปพลิเคชันและระบบปฏิบัติการ การประมวลผลแบบมัลติเธรด และปัจจัยอื่นๆ
2. การใช้ RAM (การใช้หน่วยความจำ, Mb)หน่วยวัดที่แสดงจำนวนหน่วยความจำที่ใช้โดยแอปพลิเคชัน หน่วยความจำที่ใช้สามารถแบ่งออกเป็นสามประเภท:
- เสมือน - จำนวนพื้นที่ที่อยู่เสมือนที่โปรเซสเซอร์ใช้ วอลุ่มนี้ไม่จำเป็นต้องหมายความถึงการใช้พื้นที่ดิสก์หรือ RAM ที่เหมาะสม พื้นที่เสมือนมีจำกัด และกระบวนการอาจถูกจำกัดในความสามารถในการโหลดไลบรารีที่จำเป็น
- ส่วนตัว - จำนวนพื้นที่ที่อยู่ซึ่งโปรเซสเซอร์ครอบครองและไม่ได้แชร์กับกระบวนการอื่น
- Working Set - ชุดของเพจหน่วยความจำที่กระบวนการใช้ล่าสุด เมื่อมีหน่วยความจำว่างเพียงพอ เพจจะยังคงอยู่ในชุดแม้ว่าจะไม่ได้ใช้งานก็ตาม หากมีหน่วยความจำว่างเหลือน้อย เพจที่ใช้จะถูกลบ
เมื่อแอปพลิเคชันทำงาน หน่วยความจำจะเต็มไปด้วยการอ้างอิงถึงอ็อบเจ็กต์ ซึ่งหากไม่ได้ใช้ ก็สามารถล้างข้อมูลได้ด้วยกระบวนการอัตโนมัติพิเศษที่เรียกว่าตัวรวบรวมขยะ คนเก็บขยะ- เวลาที่โปรเซสเซอร์ใช้เพื่อล้างหน่วยความจำในลักษณะนี้อาจมีความสำคัญเมื่อกระบวนการครอบครองหน่วยความจำที่มีอยู่ทั้งหมด (ใน Java ที่เรียกว่า "persistent Full GC") หรือเมื่อกระบวนการมีการจัดสรรหน่วยความจำจำนวนมากซึ่งจำเป็นต้อง ได้รับการเคลียร์ ในช่วงเวลาที่ใช้ในการล้างหน่วยความจำ การเข้าถึงเพจของหน่วยความจำที่จัดสรรของกระบวนการอาจถูกบล็อก ซึ่งอาจส่งผลต่อเวลาการประมวลผลขั้นสุดท้ายสำหรับกระบวนการนั้น
3. การใช้ทรัพยากรเครือข่ายหน่วยวัดนี้ไม่เกี่ยวข้องโดยตรงกับประสิทธิภาพของแอปพลิเคชัน แต่สามารถระบุขีดจำกัดประสิทธิภาพของระบบโดยรวมได้
| ตัวอย่างที่ 3:
แอปพลิเคชันเซิร์ฟเวอร์ที่ประมวลผลคำขอของผู้ใช้ส่งคืนสตรีมวิดีโอให้เขาโดยใช้ช่องสัญญาณเครือข่าย 2 เมกะบิต ข้อกำหนดระบุว่าเซิร์ฟเวอร์ต้องประมวลผลคำขอของผู้ใช้ 5 รายพร้อมกัน การทดสอบโหลดแสดงให้เห็นว่าเซิร์ฟเวอร์สามารถให้ข้อมูลแก่ผู้ใช้เพียง 4 คนในเวลาเดียวกันได้อย่างมีประสิทธิภาพ เนื่องจากสตรีมมัลติมีเดียมีบิตเรต 500 กิโลบิต แน่นอนว่าการให้สตรีมนี้แก่ผู้ใช้ 5 คนพร้อมกันนั้นเป็นไปไม่ได้ เนื่องจากความจุช่องสัญญาณเครือข่ายเกิน ซึ่งหมายความว่าระบบไม่ตรงตามข้อกำหนดด้านประสิทธิภาพที่ระบุ แม้ว่าการใช้ทรัพยากรโปรเซสเซอร์และหน่วยความจำอาจต่ำก็ตาม |
การทำงานกับระบบย่อยของดิสก์อาจส่งผลกระทบอย่างมากต่อประสิทธิภาพของระบบ ดังนั้นการรวบรวมสถิติเกี่ยวกับงานของดิสก์สามารถช่วยระบุปัญหาคอขวดในพื้นที่นี้ได้ การอ่านหรือเขียนจำนวนมากอาจส่งผลให้โปรเซสเซอร์ไม่ได้ใช้งานเพื่อรอการประมวลผลข้อมูลจากดิสก์ ส่งผลให้มีการใช้ CPU เพิ่มขึ้นและเวลาตอบสนองช้าลง
5. ขอเวลาตอบกลับ msเวลาดำเนินการของแอปพลิเคชันยังคงเป็นหนึ่งในตัวบ่งชี้ที่สำคัญที่สุดของระบบหรือประสิทธิภาพของแอปพลิเคชัน เวลานี้สามารถวัดได้บนฝั่งเซิร์ฟเวอร์เป็นการวัดเวลาที่ใช้สำหรับแบ็คเอนด์ในการประมวลผลคำขอ และทางฝั่งไคลเอ็นต์ เพื่อเป็นตัวบ่งชี้เวลาทั้งหมดที่จำเป็นสำหรับการทำให้เป็นอนุกรม/ดีซีเรียลไลซ์ การส่งต่อ และการประมวลผลคำขอ ควรสังเกตว่าไม่ใช่ทุกแอปพลิเคชันการทดสอบประสิทธิภาพที่สามารถวัดทั้งสองเวลานี้ได้
ดูสิ่งนี้ด้วย
ลิงค์
- แพลตฟอร์มสำหรับบริการทดสอบเว็บไซต์และซอฟต์แวร์ (รัสเซีย)
- พอร์ทัลของผู้เชี่ยวชาญด้านการทดสอบซอฟต์แวร์และการประกันคุณภาพ (รัสเซีย) - โครงการนี้จัดทำขึ้นเพื่อปัญหาการทดสอบและปรับปรุงคุณภาพของซอฟต์แวร์
- ฐานความรู้ของผู้ทดสอบ (รัสเซีย) - เครื่องมือติดตามข้อผิดพลาด การทดสอบอัตโนมัติ การทดสอบโหลด การทดสอบการใช้งาน ชุมชน สิ่งพิมพ์ หนังสือ
- การทดสอบโหลดอัตโนมัติ (รัสเซีย)
- หมายเหตุเกี่ยวกับการทดสอบโหลด (ภาษารัสเซีย)
วรรณกรรม
- ลิซ่า คริสปิน, เจเน็ต เกรกอรีการทดสอบ Agile: คู่มือปฏิบัติสำหรับผู้ทดสอบและทีม Agile - อ.: “วิลเลียมส์”, 2553. - 464 น. - (ซีรีส์ลายเซ็นแอดดิสัน-เวสลีย์) - 1,000 เล่ม - ไอ 978-5-8459-1625-9
มูลนิธิวิกิมีเดีย 2010.
> การทดสอบโหลด
การทดสอบโหลดหรือการทดสอบประสิทธิภาพ
การทดสอบความเครียดหรือ การทดสอบประสิทธิภาพ- นี่คือการทดสอบอัตโนมัติที่จำลองการทำงานของผู้ใช้ทางธุรกิจจำนวนหนึ่งในทรัพยากรทั่วไป (แบ่งปันโดยพวกเขา)
การทดสอบประสิทธิภาพประเภทหลัก
พิจารณาประเภทหลักของการทดสอบโหลด รวมถึงงานที่เผชิญอยู่
การทดสอบประสิทธิภาพ (การทดสอบประสิทธิภาพ)วัตถุประสงค์ของการทดสอบประสิทธิภาพคือเพื่อกำหนดความสามารถในการปรับขนาดของแอปพลิเคชันภายใต้โหลด และเกิดสิ่งต่อไปนี้:
- กำหนดจำนวนผู้ใช้ที่ทำงานกับแอปพลิเคชันพร้อมกัน
- การกำหนดขอบเขตของประสิทธิภาพที่ยอมรับได้เมื่อโหลดเพิ่มขึ้น (โดยเพิ่มความเข้มข้นของการดำเนินการเหล่านี้)
- การศึกษาสมรรถนะที่โหลดความเครียดสูงและสุดขีด
การทดสอบความเครียดช่วยให้คุณตรวจสอบประสิทธิภาพของแอปพลิเคชันและระบบโดยรวมภายใต้ความเครียด และยังประเมินความสามารถของระบบในการสร้างใหม่ เช่น ให้กลับมาเป็นปกติหลังจากคลายเครียดแล้ว ความเครียดในบริบทนี้อาจทำให้ความเข้มข้นของการดำเนินการเพิ่มขึ้นเป็นค่าที่สูงมากหรือการเปลี่ยนแปลงฉุกเฉินในการกำหนดค่าเซิร์ฟเวอร์ นอกจากนี้ งานหนึ่งของการทดสอบภาวะวิกฤตอาจเป็นการประเมินประสิทธิภาพที่ลดลง ดังนั้นเป้าหมายของการทดสอบภาวะวิกฤตจึงอาจทับซ้อนกับเป้าหมายของการทดสอบประสิทธิภาพ
การทดสอบปริมาตร (การทดสอบปริมาตร)วัตถุประสงค์ของการทดสอบปริมาตรคือเพื่อรับการประเมินประสิทธิภาพเมื่อปริมาณข้อมูลในฐานข้อมูลแอปพลิเคชันเพิ่มขึ้น และเกิดสิ่งต่อไปนี้:
- การวัดเวลาดำเนินการของการดำเนินการที่เลือกที่ความเข้มข้นที่แน่นอนของการดำเนินการเหล่านี้
- สามารถกำหนดจำนวนผู้ใช้ที่ทำงานกับแอปพลิเคชันพร้อมกันได้
งานการทดสอบความเสถียร (ความน่าเชื่อถือ) คือการตรวจสอบการทำงานของแอปพลิเคชันระหว่างการทดสอบระยะยาว (หลายชั่วโมง) ด้วยระดับโหลดโดยเฉลี่ย เวลาดำเนินการอาจมีบทบาทรองในการทดสอบประเภทนี้ ในขณะเดียวกันสถานที่แรกก็คือการไม่มีหน่วยความจำรั่ว เซิร์ฟเวอร์รีสตาร์ทภายใต้ภาระงาน และด้านอื่น ๆ ที่ส่งผลต่อความเสถียรของการทำงานโดยเฉพาะ
โหลดเทียบกับการทดสอบประสิทธิภาพ
ในคำศัพท์ภาษาอังกฤษ คุณสามารถค้นหาการทดสอบประเภทอื่นได้ - การทดสอบโหลด- ทดสอบการตอบสนองของระบบต่อการเปลี่ยนแปลงโหลด (ภายในขีดจำกัดที่อนุญาต) สำหรับเราดูเหมือนว่า โหลดและประสิทธิภาพพวกเขายังคงบรรลุเป้าหมายเดียวกัน: การทดสอบประสิทธิภาพ (เวลาตอบสนอง) ภายใต้โหลดที่แตกต่างกัน นั่นเป็นเหตุผลว่าทำไมเราไม่แยกพวกเขาออกจากกัน ในขณะเดียวกันก็มีคนแบ่งได้ สิ่งสำคัญคือการเข้าใจเป้าหมายของการทดสอบประเภทนี้หรือประเภทนั้นและพยายามบรรลุเป้าหมาย
เมื่อนำเว็บเซิร์ฟเวอร์ไปใช้งานในชีวิตประจำวันคุณต้องแน่ใจก่อนว่า
จะทนต่อภาระที่วางแผนไว้ เพียงสร้างเงื่อนไขที่ใกล้ชิดกับการต่อสู้
คุณสามารถประเมินได้ว่ากำลังไฟของระบบเพียงพอหรือไม่
แอปพลิเคชันที่เกี่ยวข้องกับการสร้างเนื้อหาเว็บ และปัจจัยอื่นๆ ที่มีอิทธิพล
การทำงานของเว็บเซิร์ฟเวอร์ ในสถานการณ์เช่นนี้พวกเขาจะมาช่วยเหลือ เครื่องมือพิเศษ
ซึ่งจะช่วยในการประเมินผลงานทั้งเชิงคุณภาพและเชิงปริมาณยังไง
เว็บไซต์โดยรวมและองค์ประกอบแต่ละส่วน
ทุกอย่างเป็นไปตามแผน
ก่อนที่จะรีบเข้าสู่การต่อสู้ เราต้องคิดก่อนว่าเราต้องการอะไร
ที่ได้รับจากการทดสอบ ท้ายที่สุดการตรวจสอบก็เหมือนกับงานอื่น ๆ
ต้องมีการเตรียมการเบื้องต้น หากกำหนดปัญหาไม่ถูกต้อง
อาจได้ผลลัพธ์ที่ไม่สะท้อนความเป็นจริงได้ครบถ้วน
สถานะ. จำเป็น ขึ้นอยู่กับโหลดที่คาดไว้ของเว็บเซิร์ฟเวอร์
กำหนดเกณฑ์การทดสอบ สร้างสิ่งที่จะถือว่าประสบความสำเร็จ
แล้วประสิทธิภาพการบริการที่ไม่สามารถยอมรับได้ (เช่น เวลาตอบสนอง การโหลด
เซิร์ฟเวอร์) มีสามตัวเลือกการทดสอบ:
- การทดสอบโหลด– ประสิทธิภาพของระบบถูกกำหนดไว้
ที่ภาระงานที่กำหนดไว้ล่วงหน้าอย่างเคร่งครัด (ตามแผน, ทำงาน) - ความยืดหยุ่น (ความเครียด)– ใช้เพื่อตรวจสอบพารามิเตอร์ของระบบ
ในสภาวะที่ไม่ปกติและสุดขั้ว ภารกิจหลักระหว่างการทดสอบนี้คือ
พยายามขัดขวางระบบ ให้คุณกำหนดขั้นต่ำได้
จำนวนทรัพยากรระบบที่จำเป็นสำหรับแอปพลิเคชันเพื่อดำเนินการ ประมาณการ
ความสามารถสูงสุดของระบบและปัจจัยที่จำกัดความสามารถเหล่านี้
นอกจากนี้ยังกำหนดความสามารถของระบบในการรักษาความสมบูรณ์ของข้อมูลเมื่อใด
การเกิดสถานการณ์ฉุกเฉิน - ผลงาน– การตรวจสอบที่ครอบคลุม ได้แก่
การทดสอบสองครั้งก่อนหน้านี้ได้รับการออกแบบมาเพื่อประเมินตัวบ่งชี้ระบบทั้งหมด
ผลการทดสอบ - จำนวนผู้ใช้สูงสุด, ซึ่งสามารถ
เข้าถึงเว็บไซต์พร้อมกัน จำนวนคำขอที่ประมวลผล
แอปพลิเคชันหรือเวลาตอบสนองของเซิร์ฟเวอร์ จากผลที่ได้รับ
ผู้ดูแลเว็บและผู้ดูแลระบบเครือข่าย (คนอื่น ๆ ก็มีส่วนร่วมในการทำงานของเซิร์ฟเวอร์ด้วย
ส่วนประกอบเครือข่าย เราเตอร์ ไฟร์วอลล์ แคชและพร็อกซีเซิร์ฟเวอร์ ฐานข้อมูล
ข้อมูล ฯลฯ) จะสามารถระบุปัญหาคอขวดที่เกิดขึ้นล่วงหน้าได้
การทำงานของส่วนประกอบไม่สมดุล และแก้ไขสถานการณ์ก่อน
รวมระบบในการทำงานจริง
ในระหว่างการทดสอบ จำลองการทำงานพร้อมกันหลายร้อยรายการ
หรือผู้เยี่ยมชมหลายพันคน- เพื่อความสมจริงยิ่งขึ้นแต่ละแห่งเสมือนจริง
ผู้ใช้สามารถ “เดิน” ไปรอบๆ ไซต์ตามสถานการณ์ส่วนบุคคลและมีความเป็นส่วนตัวได้
ตัวเลือก. คุณยังสามารถจำลองจุดสูงสุดในระยะสั้นระหว่างการทดสอบได้อีกด้วย
โหลดเมื่อจำนวนผู้เยี่ยมชมเพิ่มขึ้นอย่างกะทันหันซึ่งเป็นอย่างมาก
เกี่ยวข้องกับไซต์ที่มีผู้ชมไม่เท่ากัน ดังนั้นเพื่อที่จะได้ดำเนินการอย่างเต็มที่
การทดสอบ คุณต้องรู้:
- จำนวนผู้เยี่ยมชมที่วางแผนไว้ว่าจะรับโดยเฉลี่ยที่ปริมาณการใช้งานสูงสุด
เวลาในการโหลดสูงสุด - ผู้ใช้หลายคนสามารถมีที่อยู่ IP เดียวกันและ/หรือ
รหัสผ่านการเข้าใช้งาน; - จำนวนหน้าเฉลี่ยที่ดูโดยผู้ใช้หนึ่งรายมีอยู่
ความแตกต่างในพฤติกรรมระหว่างผู้ใช้ที่ลงทะเบียนและไม่ระบุชื่อ
ความสัมพันธ์เชิงปริมาณระหว่างผู้ใช้ดังกล่าว หน้าที่เยี่ยมชมและ
เวลาที่ผู้ใช้ใช้บนโหนด - การมีอยู่ของเพจไดนามิกและเพจที่เปลี่ยนแปลงตามช่วงระยะเวลาหนึ่ง
ระยะเวลาและความถี่ที่เกิดขึ้น - มีการใช้อีเมลเพื่อยืนยันข้อมูลรับรองหรือไม่
ผู้ใช้; - ข้อมูลเพิ่มเติมอื่นใดที่ใช้ในการตรวจสอบสถานะ
ผู้ใช้ (คุกกี้); - การยืนยันอำนาจของผู้ใช้จำเป็นโดยบุคคลที่สามหรือไม่?
หรือเซิร์ฟเวอร์ระยะไกล (เช่น หมายเลขบัตรเครดิต) และไม่ว่า
มีการให้ข้อมูลสำหรับการทดสอบ - ความจุของช่องสัญญาณที่มีอยู่ ความกว้างเฉลี่ยสำหรับหนึ่งช่อง
ผู้ใช้; - ไม่ว่าการทำงานของผู้ใช้หลายคนอาจทำให้เกิดการชนกันหรือไม่
- มีการใช้การเชื่อมต่อ HTTPS ที่ปลอดภัยหรือไม่
- คุณใช้แอปเพล็ต Java, สื่อสตรีมมิ่ง, ปลั๊กอินพิเศษ, อะไร
จำเป็นในฝั่งไคลเอ็นต์เพื่อสนับสนุนพวกเขา - ไม่ว่าจะใช้การแคชหน้าหรือไม่
- เหตุการณ์ทางเทคนิคที่วางแผนไว้ซึ่งอาจส่งผลกระทบต่อการดำเนินงาน
เซิร์ฟเวอร์ และเวลาในการใช้งาน (การซิงโครไนซ์ การเก็บถาวร ฯลฯ)
พารามิเตอร์เหล่านี้อาจส่งผลต่อผลลัพธ์สุดท้าย ไม่จำเป็น
หากต้องการรวมการตรวจสอบทั้งหมดไว้ในการทดสอบครั้งเดียว คุณสามารถแบ่งงานออกเป็นงานย่อยก่อนได้
ตัวอย่างเช่น การตรวจสอบระบบพื้นฐาน (เซิร์ฟเวอร์: เว็บ แอปพลิเคชัน ฐานข้อมูล) และ
การตรวจสอบแต่ละโมดูล (เซิร์ฟเล็ต สคริปต์ ฯลฯ เช่น การตรวจสอบ
การตรวจสอบสิทธิ์สำหรับผู้ใช้จำนวนมาก) ส่งผลให้เมื่อ
การทดสอบจะสร้างกราฟได้สามประเภท: เชิงเส้น ไม่เชิงเส้น และความอิ่มตัว ใน
ในกรณีแรก เมื่อโหลดเพิ่มขึ้น เวลาตอบสนอง (เช่น การประมวลผล) จะยังคงอยู่
ถาวร. เมื่อโหลดเพิ่มขึ้น เวลาตอบสนองก็จะเพิ่มขึ้นด้วย
(เกือบเป็นเส้นตรง) และในที่สุดสถานการณ์ที่คล้ายกับการโจมตีของ DOS ก็เกิดขึ้นเมื่อเวลาผ่านไป
การตอบสนองเพิ่มขึ้นอย่างไม่สิ้นสุด เมื่อแผนปฏิบัติการพร้อมแล้ว เรามาต่อกันที่
ภาพรวมโดยย่อของยูทิลิตี้ที่จะช่วยนำไปใช้งาน เริ่มจากของฟรีกันก่อน
สถาปัตยกรรมการทดสอบระบบเปิด
เปิดSTA(www.opensta.org)
- เป็นมากกว่าแอปพลิเคชันทดสอบ แต่เป็นสถาปัตยกรรมแบบเปิดที่ได้รับการออกแบบ
รอบมาตรฐานเปิด โครงการนี้ถูกสร้างขึ้นในปี พ.ศ. 2544 โดยกลุ่มบริษัท ไซราโน,
ซึ่งสนับสนุนผลิตภัณฑ์เวอร์ชันเชิงพาณิชย์ แต่ CYRANO ถูกยกเลิกและตอนนี้
เปิดSTAแจกจ่ายเป็นแอปพลิเคชันโอเพ่นซอร์สภายใต้ใบอนุญาต
GNU GPL ทำงานบน Windows NT 4.0SP5/2000/XP ต้องใช้ข้อมูลของ Microsoft ในการทำงาน
Access Components (MDAC) ซึ่งสามารถดาวน์โหลดได้จากเว็บไซต์ของบริษัท
เครื่องมือปัจจุบันอนุญาตให้มีการทดสอบโหลด HTTP/HTTPS
บริการต่างๆ แม้ว่าสถาปัตยกรรมจะมีความสามารถมากกว่าก็ตาม เปิดSTAอนุญาต
สร้างสคริปต์ทดสอบในภาษาพิเศษ SCL (Script Control
ภาษา). เพื่อให้การสร้างและแก้ไขสคริปต์ง่ายขึ้น ให้ใช้
เครื่องมือพิเศษ Script Modeler เลือกเครื่องมือ - กำหนด URL ให้เป็นมาตรฐาน
เว็บเบราว์เซอร์จะเปิดขึ้น เราแค่เดินไปรอบๆ ไซต์ รวบรวมลิงก์ที่จะ
บันทึกลงในสคริปต์ พารามิเตอร์คำขอทั้งหมดสามารถแก้ไขได้ก็เป็นไปได้
การทดแทนตัวแปร โครงสร้างการทดสอบและส่วนหัวจะแสดงในแท็บ
ในแผงด้านซ้าย สะดวกในการรวมการทดสอบเป็นชุด การตั้งค่าพร็อกซีระบุไว้ใน
สคริปต์ของตัวเอง ดังนั้นคุณจึงสามารถระบุเซิร์ฟเวอร์ได้หลายเครื่อง ความเป็นไปได้ที่นำมาใช้
การจัดการทดสอบแบบกระจายที่เพิ่มความสมจริงหรือเมื่อใด
ไม่สามารถโหลดเซิร์ฟเวอร์ที่มีประสิทธิภาพจากคอมพิวเตอร์เครื่องเดียวได้ รถแต่ละคันก็เป็นแบบนี้
ระบบสามารถดำเนินการกลุ่มงานของตัวเองได้ และโฮสต์พื้นที่เก็บข้อมูลจะรวบรวม
และการเก็บผล หลังจากติดตั้งในแต่ละระบบทดสอบแล้ว
เนมเซิร์ฟเวอร์เริ่มต้นขึ้น ซึ่งจำเป็นต้องมีการดำเนินการ ได้รับการสนับสนุน
การรับรองความถูกต้องของผู้ใช้บนทรัพยากรบนเว็บและการสร้างการเชื่อมต่อผ่าน
โปรโตคอล SSL สามารถควบคุมพารามิเตอร์การทำงานของระบบที่โหลดได้
โดยใช้เครื่องมือ SNMP และ Windows NT ผลการทดสอบรวมถึงเวลา
การตอบกลับ จำนวนไบต์ที่ถ่ายโอนต่อวินาที รหัสการตอบกลับสำหรับแต่ละคำขอ
และจำนวนข้อผิดพลาดจะแสดงเป็นตารางและกราฟ ใช้ขนาดใหญ่
จำนวนตัวกรองทำให้คุณสามารถเลือกผลลัพธ์ที่จำเป็นได้ ผลลัพธ์ที่ได้ก็คือ
ส่งออกเป็นไฟล์ CSV ความสามารถในการส่งออกรายงานค่อนข้างจำกัด
แต่การคลิกลิงก์บนเว็บไซต์ คุณจะพบสคริปต์และปลั๊กอินที่ลดความซับซ้อนเหนือสิ่งอื่นใด
การวิเคราะห์ข้อมูลที่ได้รับ
อาปาเช่ เจมิเตอร์
อาปาเช่ เจมิเตอร์(jakarta.apache.org/jmeter)
เป็นแอปพลิเคชัน Java โอเพ่นซอร์สที่ออกแบบมาเพื่อการโหลด
การทดสอบไม่เพียงแต่เว็บแอปพลิเคชันและส่วนประกอบแต่ละรายการ (สคริปต์
เซิร์ฟเล็ต, วัตถุ Java ฯลฯ ) แต่ยังรวมถึงเซิร์ฟเวอร์ FTP ฐานข้อมูล (ด้วย
โดยใช้ JDBC) และเครือข่าย ฟังก์ชันการทำงานได้รับการขยายโดยใช้ปลั๊กอิน
รองรับ SSL (ผ่าน Java Secure Sockets Extension) เป็นไปได้
ทดสอบทั้งโดยใช้อินเทอร์เฟซแบบกราฟิกและจากบรรทัดคำสั่ง
การใช้ Java หมายถึงข้ามแพลตฟอร์มดังนั้น เจมีเตอร์
ทำงานได้อย่างมั่นใจในระบบ *nix ต่างๆ ใน Windows ตั้งแต่ 98 และอื่นๆ
ระบบปฏิบัติการ เผยแพร่ภายใต้ใบอนุญาต Apache
ใน เจมีเตอร์กลไกการอนุญาตเสมือน
ผู้ใช้ เซสชันผู้ใช้ เทมเพลต การแคช และ
การวิเคราะห์ผลการทดสอบแบบออฟไลน์ในภายหลัง ฟังก์ชันช่วยให้คุณสร้างได้
คำขอถัดไปขึ้นอยู่กับการตอบสนองของเซิร์ฟเวอร์ต่อคำขอก่อนหน้า ฉันมีโอกาส
ดำเนินการทดสอบแบบกระจาย ในกรณีนี้คอมพิวเตอร์เครื่องหนึ่งก็คือ
เซิร์ฟเวอร์ (bin/jmeter-server.bat) ซึ่งจัดการไคลเอ็นต์และรวบรวม
ข้อมูลสรุป
หากต้องการทำงาน เพียงเรียกใช้ ApacheJMeter.jar หรือ jmeter.bat ในคอนโซล
(Windows) หรือ jmeter.sh (*ระวัง)
เจมีเตอร์มีพร็อกซีเซิร์ฟเวอร์ในตัวที่ออกแบบมาเพื่อบันทึก
เซสชัน แต่คุณสามารถใช้เซสชันภายนอกได้ ก่อนที่จะเริ่มการทดสอบคุณต้อง
สร้างแผนการทดสอบโดยอธิบายชุดงานที่ต้องทำให้เสร็จ
เจมีเตอร์- จะต้องมีกลุ่มเธรดตั้งแต่หนึ่งกลุ่มขึ้นไป (Thread
กลุ่ม) และองค์ประกอบอื่นๆ:
- ตัวควบคุมลอจิก;
- ตัวควบคุมการสร้างตัวอย่าง
- ผู้ฟัง;
- ตัวจับเวลา;
- การยืนยัน;
- องค์ประกอบการกำหนดค่า
ก่อนอื่น ให้เพิ่มกลุ่มเธรด (แก้ไข - เพิ่ม - กลุ่มเธรด) ในตัวเธอ
ในการตั้งค่าเราระบุชื่อจำนวนเธรดที่จะเปิดนั่นคือ
ผู้ใช้เสมือน (จำนวนเธรด) การหน่วงเวลาระหว่างการเปิดตัว
เธรด (Ramp-Up Period), จำนวนรอบการดำเนินการ (จำนวนลูป),
ที่นี่ คุณยังสามารถกำหนดการดำเนินงานตามกำหนดการ (Sheduler) ได้ ไกลออกไป,
เมื่อคลิกในกลุ่มที่สร้างขึ้น คุณจะต้องเพิ่มคำขอตัวอย่าง (Sampler) โดยการเลือก
จากรายการ สำหรับการทดสอบโหลดหรือการทดสอบประสิทธิภาพ
เซิร์ฟเวอร์ เพียงเลือกคำขอ HTTP (เพิ่ม -ตัวอย่าง - คำขอ HTTP) ที่นี่
ระบุชื่อ ที่อยู่ IP และพอร์ตของเว็บเซิร์ฟเวอร์ โปรโตคอล วิธีการถ่ายโอนข้อมูล
(GET, POST), พารามิเตอร์การเปลี่ยนเส้นทาง, การถ่ายโอนไฟล์ไปยังเซิร์ฟเวอร์ เรากำหนดค่าและ
คลิกที่เรียกใช้ ผลลัพธ์ของผลลัพธ์จะดำเนินการโดยใช้ Listeners แต่ละรายการ
แสดงผลในแบบของตัวเอง ตัวอย่างเช่น กราฟรวมจะแสดงยอดรวม
ผลการทดสอบในรูปแบบตารางและกราฟ
อนิจจาผลิตภัณฑ์ฟรีสิ้นสุดลงแล้ว ขณะนี้มีโซลูชันเชิงพาณิชย์อยู่สองสามรายการ
WAPT – การทดสอบแอปพลิเคชันเว็บ
WAPT(www.loadtestingtool.com)
ช่วยให้คุณสามารถทดสอบความเสถียรของเว็บไซต์และแอปพลิเคชันอื่น ๆ ที่ใช้
เว็บอินเตอร์เฟสเพื่อโหลดจริง พัฒนาโดยบริษัทโนโวซีบีสค์
ซอฟท์ลอจิก้า แอลแอลซี นี่เป็นหนึ่งในโปรแกรมตรวจสอบที่ง่ายที่สุดในการใช้งาน สำหรับ
เพื่อทำการทดสอบง่ายๆ คุณไม่จำเป็นต้องดูเอกสารประกอบหรืออินเทอร์เฟซด้วยซ้ำ
เรียบง่ายแต่ไม่ได้แปลเป็นภาษาท้องถิ่น รัน Windows 98 เป็นต้นไป รองรับ
และวิสต้า สำหรับเช็ค WAPTสามารถสร้างเสมือนจริงได้มากมาย
ผู้ใช้แต่ละคนมีพารามิเตอร์เฉพาะตัว รองรับหลายรายการ
ประเภทของการรับรองความถูกต้องและคุกกี้ สคริปต์ช่วยให้คุณเปลี่ยนความล่าช้าระหว่าง
แบบสอบถามและสร้างพารามิเตอร์การทดสอบแบบไดนามิก
จึงเป็นการเลียนแบบพฤติกรรมของผู้ใช้จริงให้มากที่สุด การร้องขอ
ตัวเลือกส่วนหัว HTTP ต่างๆ สามารถทดแทนได้ในการตั้งค่าที่คุณสามารถทำได้
ระบุการเข้ารหัสหน้า มีการระบุพารามิเตอร์ User-Agent, X-Forwarded-For, IP
ในการตั้งค่าสคริปต์ สามารถคำนวณค่าพารามิเตอร์แบบสอบถามได้
ในหลายๆ ด้าน รวมถึงพิจารณาจากการตอบสนองของเซิร์ฟเวอร์ต่อครั้งก่อนด้วย
แบบสอบถามโดยใช้ตัวแปรและฟังก์ชัน รองรับการทำงานผ่านระบบรักษาความปลอดภัย
โปรโตคอล HTTPS (และพร็อกซีเซิร์ฟเวอร์ทุกประเภท) สคริปต์ที่สร้างบันทึกไว้ใน
ไฟล์ XML สามารถนำมาใช้ซ้ำได้ นอกเหนือจากมาตรฐานประสิทธิภาพและ
ความเครียด รายการนี้มีการทดสอบอื่นๆ อีกหลายรายการที่ช่วยให้คุณตัดสินใจได้
จำนวนผู้ใช้สูงสุดและทดสอบเซิร์ฟเวอร์ขณะโหลดเข้า
เป็นเวลานาน
เพื่อดำเนินการทดสอบ คุณต้องเลือก ใหม่ - สถานการณ์สมมติ
วิซาร์ดการสร้างการทดสอบจะเปิดขึ้น ในขั้นตอนแรก ประเภทของการทดสอบจะถูกระบุและจากนั้น
แต่ละหน้าต่างจะเต็มไปด้วยพารามิเตอร์ของการทดสอบในอนาคต ที่นี่คุณสามารถระบุได้
จำนวนผู้ใช้เสมือนคงที่หรือเพิ่มขึ้นทีละขั้นตอน
ระบุจำนวนขั้นต่ำและสูงสุดและช่วงเวลาที่ตั้งไว้
ตัวจับเวลาการทดสอบ ขั้นตอนต่อไปคือการตั้งเวลาระหว่างการคลิก (คิด
เวลา) ความเร็วในการเชื่อมต่อ ระบุช่วงของที่อยู่ IP ที่จะเป็น
ใช้โดยผู้ใช้เสมือน การคลิกที่รายการที่อยู่ IP จะอนุญาต
จัดทำรายการที่อยู่ดังกล่าว พารามิเตอร์ HTTP User-Agent และ
เปิดใช้งานการจำลองพร็อกซีแล้ว หากคุณต้องการให้ผู้ใช้เสมือนมี
การตั้งค่าส่วนบุคคลในขั้นตอนถัดไปของวิซาร์ดสำหรับแต่ละการตั้งค่า
คุณต้องสร้างโปรไฟล์ของคุณโดยคลิกใหม่หรือโหลดโปรไฟล์ที่บันทึกไว้ ในครั้งต่อไป
ในหน้าต่างโปรแกรม คุณต้องตั้งค่าพารามิเตอร์โปรไฟล์
หลังจากคลิกปุ่ม Finish สคริปต์จะถูกบันทึก ตอนนี้จะชี้ให้เห็นว่า
ทดสอบวัตถุ สร้างโปรไฟล์ ใหม่ – โปรไฟล์ และกรอกพารามิเตอร์ทั้งหมด
แท็บ ที่นี่คุณสามารถแก้ไขพารามิเตอร์บางตัวที่ระบุได้ที่นี่
ก่อนหน้านี้ด้วยความช่วยเหลือจากปรมาจารย์ นอกจากนี้ยังระบุการโหลดภาพวาดโดยเสมือนจริงด้วย
ผู้ใช้ พารามิเตอร์การรับรองความถูกต้อง การใช้คุกกี้ และอื่นๆ
บนแท็บ Recorder ระบุที่อยู่ของไซต์ซึ่งสามารถใช้งานได้ทันที
ตรวจสอบโดยคลิกไป ในเวลาเดียวกันคำขอให้เปิดตัว Recorder จะตามมาซึ่ง
จะติดตามหน้าที่เข้าชมและบันทึก URIs (จะถูกแสดงใน
แผงด้านซ้าย) เมื่อรวบรวมข้อมูลทั้งหมดแล้ว คลิกเรียกใช้การทดสอบ รายงานโดยละเอียด
จะแสดงเป็นกราฟระหว่างการทดสอบ
หน้า HTML ถูกสร้างขึ้น ส่งผลให้สามารถรับข้อมูลเกี่ยวกับเวลาได้
การตอบสนองของเซิร์ฟเวอร์พร้อมโหลดที่เพิ่มขึ้นตามจำนวนข้อผิดพลาดที่ส่งและ
ไบต์ที่ได้รับ ฯลฯ
นีโอโหลด
นีโอโหลด(www.neotys.com)
- อีกระบบหนึ่งที่ให้คุณทำการทดสอบโหลดได้
แอปพลิเคชันเว็บ เขียนด้วยภาษา Java ทำงานบนคอมพิวเตอร์ที่ทำงานอยู่
ใช้งาน Windows NT/2000/XP, Linux และ Solaris ในรายงานคุณจะได้รับ
ข้อมูลโดยละเอียดสำหรับไฟล์ที่ดาวน์โหลดแต่ละไฟล์ NeoLoad สะดวกมากสำหรับ
การประเมินประสิทธิภาพของแต่ละส่วนประกอบ (AJAX, PHP, ASP, CGI, Flash, แอพเพล็ต และ
ฯลฯ) สามารถตั้งเวลาหน่วงระหว่างคำขอ (เวลาคิด) ได้ทั่วโลก
และแยกกันสำหรับแต่ละหน้า การทดสอบจะดำเนินการเช่นเดียวกับ
ใช้เชลล์กราฟิกที่สะดวกมากและใช้คำสั่ง
สตริง (โดยใช้ไฟล์ XML ที่เตรียมไว้ล่วงหน้า) รองรับการทำงานด้วย
โปรโตคอล HTTPS พร้อมด้วยพร็อกซี HTTP และ HTTPS การตรวจสอบเว็บขั้นพื้นฐานและคุกกี้
ตรวจจับข้อมูลโดยอัตโนมัติขณะบันทึกสคริปต์ จากนั้นจึงเล่นกลับ
เวลาทดสอบ เพื่อทำงานกับโปรไฟล์ต่าง ๆ สำหรับการลงทะเบียนผู้ใช้
สามารถใช้ตัวแปรได้ เมื่อทำการทดสอบคุณสามารถใช้
จอภาพเพิ่มเติม (SNMP, WebLogic, WebSphere, RSTAT และ Windows, Linux,
Solaris) ช่วยให้คุณสามารถควบคุมพารามิเตอร์ของระบบที่รันได้
เว็บเซิร์ฟเวอร์.
ด้วยความช่วยเหลือ นีโอโหลดคุณยังสามารถเรียกใช้การทดสอบแบบกระจายได้ หนึ่งใน
คอมพิวเตอร์เป็นตัวควบคุม ส่วนเครื่องกำเนิดไฟฟ้าจะถูกติดตั้งในส่วนที่เหลือ
โหลด (loadGenerator) คอนโทรลเลอร์จะกระจายโหลดระหว่าง loadGenerator และ
รวบรวมสถิติ
การทำงานกับผู้ใช้เสมือนนั้นสะดวกมาก ผู้ใช้
มีการตั้งค่าส่วนบุคคล จากนั้นจึงรวมเข้ากับประชากร (should
ต้องสร้างประชากรอย่างน้อยหนึ่งรายการ) ในประชากรคุณสามารถตั้งค่าทั่วไปได้
พฤติกรรม (เช่น 40% ของผู้ใช้ประชากรเยี่ยมชมทรัพยากรแบบไดนามิก
อ่านข่าว 20%) ผู้ใช้เสมือนสามารถมีรายบุคคลได้
ที่อยู่ IP แบนด์วิดท์ และสคริปต์ทดสอบของคุณ
เป็นเรื่องง่ายมากที่จะสร้างสถานการณ์จำลองสำหรับการทดสอบในอนาคต เปิดแอปพลิเคชัน (ถ้า
การเปิดตัวครั้งแรกคุณจะต้องป้อนรหัสการลงทะเบียน เวอร์ชัน 30 วันหลังจากนั้น
การลงทะเบียนจะถูกส่งทางไปรษณีย์) เลือก New Project ใส่ชื่อ
โครงการ. หลังจากนี้ จะมีการแสดงคำใบ้เล็กๆ น้อยๆ เกี่ยวกับเรื่องต่อไป
การกระทำ การคลิกเริ่มการบันทึกจะเป็นการเปิดเว็บเบราว์เซอร์ การเคลื่อนไหวทั้งหมดจะเป็น
บันทึก เมื่อเสร็จแล้ว คลิกหยุดการบันทึกหรือปิดเบราว์เซอร์
ตัวช่วยสร้างจะเปิดตัวซึ่งจะช่วยคุณสร้างผู้ใช้เสมือนและ
จะค้นหาพารามิเตอร์แบบไดนามิกในหน้าที่บันทึกไว้โดยอัตโนมัติ
จะกำหนดค่าเวลาคิดเฉลี่ย ส่วนประกอบของหน้า (HTML, รูปภาพ, CSS)
จะถูกบันทึกไว้แยกต่างหาก เพื่อให้ได้ผลลัพธ์ คุณต้องดำเนินการสามขั้นตอน:
- การออกแบบ - การตั้งค่าโครงการ มีสามแท็บ พื้นที่เก็บข้อมูลบ่งชี้
หน้าเว็บและพารามิเตอร์การสืบค้นใน Virtual User virtual
ผู้ใช้ ระบุ URL ที่พวกเขาควร "เข้าชม" และอื่นๆ
เงื่อนไขจากแท็บด้านซ้ายของช่องการดำเนินการ ในประชากร – งานสำหรับแต่ละกลุ่ม
ผู้ใช้ สามารถเลือกการดำเนินการต่อไปนี้ได้ในการดำเนินการ: ความล่าช้า
(ตั้งค่าดีเลย์), วนซ้ำ (ขอซ้ำ), While (วนรอบ), ถ้า...จากนั้น...อย่างอื่น
(เงื่อนไข), คอนเทนเนอร์ และคอนเทนเนอร์สุ่ม (การดำเนินการกลุ่ม), ลอง...จับ
(การจัดการข้อผิดพลาด), หยุดผู้ใช้เสมือน (หยุดการทำงานของ virtual
ผู้ใช้) - รันไทม์ – ระบุพารามิเตอร์การทดสอบ การทดสอบจะดำเนินการ ที่นี่ใน
สถิติจะแสดงในแท็บแยกกันเมื่อการทดสอบดำเนินไป - ผลลัพธ์ – ทำหน้าที่แสดงสถิติต่างๆ ในรูปแบบตาราง และกราฟ
นอกจากนี้ นอกเหนือจากค่าทั่วไปแล้ว คุณยังสามารถเลือกระบบตัวกรองได้อีกด้วย
ข้อมูลพารามิเตอร์ใดๆ หากต้องการสามารถบันทึกโครงการเพื่อนำกลับมาใช้ใหม่ได้
ใช้. ในบรรดาผลิตภัณฑ์ที่นำเสนอความสามารถในการเปรียบเทียบผลลัพธ์
มีเพียงการทดสอบเท่านั้นที่มี นีโอโหลด.
การใช้ยูทิลิตี้ทดสอบโหลดคุณสามารถรับข้อมูลเกี่ยวกับ
การดำเนินงานบริการเว็บใช้มาตรการที่จำเป็นเพื่อกำจัดการระบุ
ข้อบกพร่องและรับประกันประสิทธิภาพที่ต้องการ
ผลิตภัณฑ์จากไมโครซอฟต์
Microsoft Corporation นำเสนอผลิตภัณฑ์สองรายการที่อนุญาต
ทดสอบเว็บเซิร์ฟเวอร์ภายใต้ภาระงาน นี้ ความเครียดแอปพลิเคชัน Microsoft
เครื่องมือและ เครื่องมือวิเคราะห์ความจุเว็บ- อันแรกแจกเป็น
ผลิตภัณฑ์แยกต่างหากและมีอินเทอร์เฟซแบบกราฟิก อันที่ 2 รวมอยู่ด้วย
ชุดเครื่องมือ เครื่องมือชุดทรัพยากรบริการข้อมูลทางอินเทอร์เน็ต 6.0,
ทำงานจากบรรทัดคำสั่ง เสาเห็นภาพมากขึ้นในการสร้างแบบทดสอบ
วิซาร์ดง่ายๆ สำหรับการสร้างการทดสอบจะช่วยได้ คุณสามารถทำงานกับคุกกี้และปรับเปลี่ยนได้
โหลดบน URL ที่แตกต่างกัน สามารถสร้างสคริปต์ทดสอบได้ด้วยตนเองหรือ
บันทึกโดยใช้เว็บเบราว์เซอร์และแก้ไขหากจำเป็น ใน ขยะ
ระดับความเค้นจะถูกปรับระดับโดยการตั้งค่าจำนวนเธรด
การร้องขอไปยังเซิร์ฟเวอร์และจำนวนผู้ใช้เสมือน
คำนวณเป็นผลคูณของจำนวนเธรดและจำนวนซอคเก็ตที่เปิดโดยแต่ละอัน
หัวข้อ เมื่อสิ้นสุดการทดสอบ เราได้รับรายงานง่ายๆ ในรูปแบบข้อความ ซึ่งในนั้น
ข้อมูลจะได้รับตามจำนวนคำขอที่ประมวลผลต่อหน่วยเวลาโดยเฉลี่ย
เวลาหน่วง, ความเร็วในการถ่ายโอนข้อมูลเข้าและออกจากเซิร์ฟเวอร์, หมายเลข
ข้อผิดพลาด ฯลฯ รายงานสามารถส่งออกเป็นไฟล์ CSV ไม่มีตัวเลือกสำหรับ
ไม่มีการประมวลผลทางสถิตินั่นคือด้วยความช่วยเหลือที่คุณสามารถทำได้เท่านั้น
ประเมินประสิทธิภาพภายใต้เงื่อนไขบางประการ
