โหลดทดสอบแอป Rails ของคุณด้วย Apache JMeter

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

• พฤติกรรมของผู้ใช้อาจคาดเดาไม่ได้
• มีการกระจายผู้ใช้ตามสถานที่ต่างๆ
• ผู้ใช้จำนวนมากสามารถใช้แอปพลิเคชันได้พร้อมกัน

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

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

การทดสอบโหลดคืออะไร และแตกต่างจากการทดสอบประสิทธิภาพอย่างไร

คำสามคำต่อไปนี้อาจฟังดูคล้ายกันแต่ต่างกัน:

• การทดสอบประสิทธิภาพ
• โหลดการทดสอบ และ
• การทดสอบความเครียด

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

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

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

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

เหตุใดการทดสอบประสิทธิภาพจึงสำคัญ

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

• หากคาดว่าแอปพลิเคชันจะมีผู้ใช้เพิ่มขึ้นอย่างรวดเร็วในวันใดวันหนึ่ง เช่น วัน Black Friday การทดสอบแอปพลิเคชันอย่างรวดเร็วด้วยช่วงเวลาสั้นๆ จะช่วยให้เราพบปัญหาที่อาจเกิดขึ้นในระบบ
• การทดสอบการโหลดช่วยระบุจุดบกพร่องในระบบที่มองไม่เห็นหรือน้อยมากเมื่อมีผู้ใช้เพียงไม่กี่คน
• ช่วยให้เราประเมินว่าความเร็วของแพลตฟอร์มได้รับผลกระทบจากภาระที่เพิ่มขึ้นอย่างไร หากแอปพลิเคชันช้า เราอาจสูญเสียลูกค้า
• ช่วยประเมินว่าระบบของเราทำงานอย่างไรภายใต้ภาระที่เพิ่มขึ้น และระบบขัดข้องด้วยการใช้ CPU หรือหน่วยความจำสูงเมื่อมีผู้ใช้ 10,000 ราย
• ค่าใช้จ่ายในการเรียกใช้แอปพลิเคชันสำหรับผู้ใช้จำนวนหนึ่งสามารถกำหนดได้ด้วยการทดสอบโหลด

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

การใช้ Apache JMeter เพื่อโหลดแอป Rails ทดสอบ

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

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

สามารถดาวน์โหลด JMeter ได้จากลิงก์ต่อไปนี้:https://jmeter.apache.org/download_jmeter.cgi#binaries

คำศัพท์เฉพาะของ JMeter ที่คุ้นเคย

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

ในการรันการทดสอบโหลด เราต้องสร้างไฟล์ JMX ก่อน โดยเราจะกำหนดคำศัพท์ JMeter ที่อธิบายข้างต้น

การเตรียมไฟล์ JMX สำหรับการทดสอบการโหลด

JMX เป็นไฟล์โครงการ JMeter ที่เขียนในรูปแบบ XML การเขียนไฟล์ JMX ด้วยตนเองอาจเป็นเรื่องยาก ดังนั้นเราจะใช้อินเทอร์เฟซ JMeter เพื่อสร้างไฟล์

เปิดอินเทอร์เฟซ JMeter และค้นหาแผนการทดสอบ ภายในแผนการทดสอบ เราจะเพิ่มเธรดและการกำหนดค่าการทดสอบโหลด

อินเทอร์เฟซ JMeter สำหรับสร้างแผนการทดสอบ

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

Add -> Threads(Users) -> Thread Group

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

เนื่องจากเราจะโหลดการทดสอบแอป Rails บนเว็บ เราจะเพิ่มตัวอย่าง HTTP เราสามารถเพิ่ม Sampler ซึ่งจะอยู่ใน ThreadGroup . เพิ่ม HTTP Sampler โดยเข้าไปที่:

Add -> Sampler -> HTTP Request

ที่นี่ เรากำหนดค่า IP หรือโดเมนที่เรากำลังทดสอบโหลด และวิธีการ HTTP และเนื้อหาคำขอใดๆ ที่จำเป็นสำหรับปลายทาง HTTP

สุดท้าย หากต้องการดูรายงานการทดสอบโหลด เราสามารถเพิ่ม Listener ในกลุ่มเธรดได้

Add -> Listener -> View Result Tree

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

ด้วยวิธีนี้ เราสามารถสร้างแผนการทดสอบอย่างง่ายและดำเนินการได้ เพียงกดที่ไอคอนเล่นที่แถบด้านบนของ JMeter เพื่อดำเนินการทดสอบ

สิ่งที่ต้องพิจารณาก่อนโหลดการทดสอบแอป Rails

ตัวอย่างข้างต้นเป็นคำขอ HTTP ปลายทางเดียวที่ง่ายมาก ในกรณีของแอป Rails ปลายทางที่เราต้องการทดสอบจะถูกล็อคด้วยการตรวจสอบสิทธิ์ ดังนั้น เราจำเป็นต้องตรวจสอบให้แน่ใจว่าเรามีสิ่งต่าง ๆ ดังต่อไปนี้:

• เว็บคุกกี้ - ปลายทาง HTTP ต้องมีส่วนหัวของคุกกี้ก่อน เราจึงจะสามารถทำการทดสอบโหลดได้ JMeter มีฟังก์ชันในการเพิ่มคุกกี้เมื่อผู้ใช้เข้าสู่ระบบ ในส่วนถัดไป เราจะดูว่าเราสามารถบันทึกคำขอของเบราว์เซอร์และแปลงเป็นไฟล์ JMX สำหรับการทดสอบโหลดของเราได้อย่างไร เราจะครอบคลุมการบันทึกคุกกี้ด้วย
• โทเค็น Rails CSRF - Rails ปกป้องแอปจากช่องโหว่ด้านความปลอดภัยโดยการจัดเตรียมโทเค็น CSRF ดังนั้นเราจำเป็นต้องตรวจสอบให้แน่ใจว่าคำขอของเรามีการรับรองความถูกต้องของ CSRF ในส่วนหัวก่อนทำการทดสอบโหลด โทเค็น CSRF นี้มีอยู่ใน header ภายใน meta แท็กใน HTML

Rails CSRF Token สามารถดึงข้อมูลใน JMeter โดยใช้ตัวประมวลผลภายหลัง คลิกขวาที่คำขอ HTTP ที่โหลดหน้าเว็บที่มีโทเค็น CSRF จากนั้นเลือก Add -> Post Processor -> Regular Expression Extractor . ที่นี่ คุณสามารถเพิ่มการกำหนดค่าตัวแยกนิพจน์ทั่วไปต่อไปนี้เพื่ออ่านค่า CSRF จากเมตาแท็กส่วนหัว:

• ชื่ออ้างอิง:csrf_value

• นิพจน์ทั่วไป:name="csrfToken" content="(.+?)"

• แม่แบบ:$1$

• หมายเลขที่ตรงกัน:1

ตอนนี้ตัวแปร csrf_value ใช้ยื่นคำร้องได้

การบันทึกคำขอจากเบราว์เซอร์เพื่อสร้างไฟล์ JMX

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

สามารถเพิ่ม JMeter เป็นพร็อกซีระหว่างแอป Rails และเบราว์เซอร์ได้ ด้วยสิ่งนี้ JMeter จะส่งคำขอทั้งหมดไปยังเซิร์ฟเวอร์ Rails สิ่งนี้เรียกว่าการโจมตี MITM (ชายตรงกลาง)

การบันทึก JMeter

ในการสร้างการบันทึกใน JMeter ให้ไปที่ file -> templates -> recording และคลิกสร้าง ระบุชื่อโฮสต์ที่คุณกำลังบันทึก สิ่งนี้จะสร้างบางสิ่งให้คุณโดยอัตโนมัติ รวมถึงตัวจัดการคุกกี้ ตัวจัดการคุกกี้จะบันทึกคุกกี้ที่จำเป็นสำหรับการตรวจสอบสิทธิ์

การยืนยันคำขอ HTTPs ด้วยใบรับรอง JMeter SSL

คำขอที่เราทำจากเบราว์เซอร์นี้จะถูกส่งต่อไปยัง JMeter และ JMeter จะส่งต่อไปยังบริการบนเว็บและบันทึกคำขอเพื่อให้เราสามารถเรียกใช้การทดสอบโหลดจากการบันทึก JMeter หากแอปพลิเคชันต้องการโปรโตคอล https สำหรับการเชื่อมต่อ SSL จะต้องเพิ่มใบรับรองลงในเบราว์เซอร์ หากต้องการเพิ่มใบรับรอง ให้เราเปิด Firefox, หรือเบราว์เซอร์อื่นๆ ใน Firefox, ไปที่ settings > Privacy > Manage certificate และเพิ่มใบรับรอง JMeter เพื่อให้เบราว์เซอร์รู้จักใบรับรองที่สร้างโดย JMeter

ป้อน cmd + sht + g และป้อนเส้นทาง /usr/local/Cellar/jmeter/5.2/libexec/bin/jmeter เพื่อเพิ่มใบรับรอง

กำหนดค่า Firefox ให้ใช้ JMeter เป็น Aa Proxy

ต่อไป เราต้องส่งต่อคำขอจาก Firefox ไปยังสคริปต์บันทึก JMeter ของเรา สามารถทำได้โดยกำหนดค่าพร็อกซีใน Firefox เปิด Firefox แล้วไปที่ Preferences -> Advanced -> Connection(settings) . ที่นี่ ตั้งค่าพร็อกซี HTTP เป็น "localhost" และพอร์ตเป็น "8080" และทำเครื่องหมายที่ "ใช้พร็อกซีเซิร์ฟเวอร์นี้สำหรับโปรโตคอลทั้งหมด"

ตอนนี้ เราสามารถไปที่ JMeter และ Script recording ส่วนจากเทมเพลตที่เราเลือกไว้ก่อนหน้านี้ เมื่อเรากดปุ่มเริ่มต้น JMeter จะเริ่มยอมรับคำขอที่เข้ามา เมื่อเราไปที่ Firefox และเรียกดูแอปพลิเคชันที่เรากำลังทดสอบโหลด การดำเนินการนี้จะบันทึกและแปลงเป็นไฟล์ JMX ซึ่งเราสามารถเรียกใช้การทดสอบโหลดได้

การทดสอบโหลดแบบกระจายด้วย JMeter

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

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

การทดสอบแบบกระจายของ JMeter

หากต้องการทำการทดสอบแบบกระจาย ให้เริ่มต้นด้วยการติดตั้ง JMeter บนเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์รอง

สิ่งที่ต้องทำบนเซิร์ฟเวอร์รอง:

• ไปที่ jmeter/bin และรัน jmeter-server สั่งการ. การดำเนินการนี้จะเริ่มเซิร์ฟเวอร์เพื่อทำการทดสอบ
• หากจำเป็นต้องใช้อินพุต CSV สำหรับการทดสอบ ให้เพิ่มไฟล์เหล่านี้ในเซิร์ฟเวอร์นี้

สิ่งที่ต้องทำบนเซิร์ฟเวอร์หลัก:

• ไปที่ไดเร็กทอรี jmeter/bin และเปิด jmeter.properties ไฟล์.
• แก้ไขบรรทัดที่มี remote_hosts และเพิ่ม IP ของเซิร์ฟเวอร์รอง โดยคั่นด้วยเครื่องหมายจุลภาค remote_hosts=<s1_ip>,<s2_ip> .
• เรียกใช้การทดสอบ JMeter

เซิร์ฟเวอร์รองจะรับผิดชอบในการทำการทดสอบจริง และเซิร์ฟเวอร์หลักจะรวบรวมรายงาน

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

> jmeter -n -t path/to/test.jxm -r

หรือ

> jmeter -n -t path/to/test.jxm -R s1_ip,s2_ip,…

-r ใช้เซิร์ฟเวอร์ระยะไกลที่ระบุใน jmeter.properties

-n จะเรียกใช้โดยไม่ต้องดัดแปลง GUI

-t เส้นทางไปยังไฟล์ jmx

วิธีที่เราตัดสินใจใช้ Puma vs. Unicorn สำหรับเซิร์ฟเวอร์ Rails ของเรา

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

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

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

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

พบความล้มเหลวทั่วไปบางอย่างขณะเน้นย้ำแอป Rails และวิธีแก้ไข

• การสืบค้นฐานข้อมูลที่ไม่ได้เพิ่มประสิทธิภาพ
  • ขจัดปัญหาการสืบค้น n+1
  • เพิ่มดัชนีตามรูปแบบการเข้าถึง
  • ใช้เลเยอร์แคชเหมือน Redis ที่ด้านหน้าของฐานข้อมูล
• ประสิทธิภาพของรหัสทับทิมช้า
  • บันทึกเพื่อเพิ่มประสิทธิภาพโค้ด
  • หาความซับซ้อนของ o(n^2) และใช้อัลกอริธึมที่เหมาะสมที่สุด
• ในสถาปัตยกรรมไมโครเซอร์วิส อาจมีการเรียก HTTP ระหว่างบริการจำนวนมาก การโทรเครือข่ายช้า
  • ลดจำนวนการโทร HTTP โดยใช้ระบบส่งข้อความสำหรับไมโครเซอร์วิส
• บันทึกเดียวกันถูกสร้างขึ้นสองครั้งเมื่อสร้างพร้อมกัน
  • เพิ่มข้อจำกัดเฉพาะฐานข้อมูล
  • ใช้การสร้างทรัพยากรตามเหตุการณ์ FIFO (คิว)
• ใช้การประมวลผลพื้นหลัง เช่น Sidekiq ทุกครั้งที่ทำได้
• กำหนด SLA สำหรับเวลาตอบสนองของ API และรวมการทดสอบประสิทธิภาพไว้เป็นส่วนหนึ่งของวงจรการพัฒนา

ควรใช้สภาพแวดล้อมใดในการทดสอบโหลด

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

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

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

ขณะทดสอบโหลด เรายังต้องการจุดข้อมูล เช่น การใช้ CPU/หน่วยความจำของเซิร์ฟเวอร์เป้าหมาย การใช้หน่วยความจำ/ซีพียูที่พุ่งสูงขึ้นอาจทำให้แอปพลิเคชันหยุดทำงาน หากต้องการวัด KPI ของฮาร์ดแวร์ ให้เพิ่มเครื่องมือตรวจสอบ เช่น Prometheus ก่อนเริ่มการทดสอบโหลด

Apache JMeter เป็นเครื่องมือที่ทรงพลังสำหรับการทดสอบโหลด เราใช้ Apache JMeter สำหรับการทดสอบโหลดแอป Rails แต่สามารถใช้เพื่อทำการทดสอบโหลด/ความเครียดของการสร้างแอปพลิเคชันบนสแต็กใดก็ได้ การทดสอบโหลดช่วยตัดสินใจโดยใช้ข้อมูลในแอปพลิเคชัน การทดสอบโหลดอาจฟังดูน่ากลัว แต่ด้วยการลงทุนเพียงเล็กน้อยในตอนเริ่มต้น ก็สามารถเพิ่มความเสถียรและความน่าเชื่อถือให้กับแอปพลิเคชันได้ในระยะยาว