Odoo Load Test Study Result

01 ผลที่วัดได้จากการทดสอบ

เราตั้งเครื่องจริงบน DigitalOcean ใส่ข้อมูลจำลอง 20,304 ใบสั่งขาย แล้วปล่อย ผู้ใช้เสมือน (Virtual User หรือ VU) เข้าไปใช้งานพร้อมกัน เพิ่มทีละขั้นตั้งแต่ 10 VU จนถึง 60 VU โดยให้แต่ละ VU เว้นจังหวะกดแบบคนจริง ทั้งเปิดดู แก้ไข และสั่งพิมพ์รายงาน

ตั้งแต่ 10 คนถึง 60 คน เวลาตอบสนองเพิ่มจาก 37 เป็น 81 มิลลิวินาที ซึ่งยังเร็วกว่าเกณฑ์อ้างอิง 1 วินาที อยู่ราวสิบสองเท่า และ CPU เพิ่มขึ้นในสัดส่วนที่คงที่ ระดับที่ทดสอบสูงกว่าค่าประมาณการใช้งานราวหกเท่า และยังใช้ CPU ประมาณหนึ่งในสี่

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

02 ระบบเริ่มช้าจนกระทบงานเมื่อใด

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

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

03 การเพิ่ม worker ไม่ได้ทำให้งานเร็วขึ้น

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

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

ข้อนี้ยังหักล้างการคาดการณ์ของเราเองด้วย ก่อนหน้านี้เราคำนวณว่า 16 workers น่าจะดันเพดานไปถึง 130 ถึง 180 คน การคำนวณนั้นตั้งอยู่บนสมมติฐานว่า CPU คือตัวที่ตัน ซึ่งผิด

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

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

04 ตัวเชื่อมมาร์เก็ตเพลสที่ยืนยันใบสั่งขาย

การทดสอบชุดแรกใช้ตัวเชื่อมที่สร้างใบสั่งขายแล้วหยุด ไม่เคยยืนยันใบสั่ง จึงไม่เคยสร้างใบส่งของและไม่เคยแตะการจองสต็อก ซึ่งเป็นเส้นทางเดียวกับที่ทำให้ระบบช้าลงในหัวข้อที่ 02 แต่ตัวเชื่อมที่ใช้งานจริงยืนยันใบสั่ง เราจึงแก้ให้ทำงานเต็มกระบวนการแล้วทดสอบใหม่

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

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

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

ตัวเชื่อมตามงานของตัวเองไม่ทัน เมื่ออยู่ลำพังทำได้ 196 ใบต่อนาที เมื่อมีผู้ใช้อยู่ด้วยทำได้ 142 ใบต่อนาที ไม่มีอะไรล้มเหลว ไม่มี error รายงานออกมา เพียงแต่ทั้งสองฝ่ายทำงานได้น้อยลง

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

05 สิ่งที่ผลทดสอบบอกเราเรื่องการวางระบบ

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

• 01แยกฐานข้อมูลออกจากเครื่องแอปตั้งแต่แรก ทุกตัวเลขในหน้านี้มาจากโครงสร้างแบบแยก ข้อดีที่เห็นชัดคือเมื่อฝั่งแอปใช้หน่วยความจำจนมีปัญหา ฐานข้อมูลจะไม่ถูกดึงลงไปด้วย และเปลี่ยนขนาดทีละฝั่งได้โดยไม่ต้องแตะอีกฝั่ง
• 02เฝ้าระวังที่เวลาตอบสนอง ไม่ใช่แค่จำนวน error นี่คือบทเรียนที่ตรงไปตรงมาที่สุดจากหัวข้อที่ 02 ตลอดการทดสอบ error อยู่ที่ศูนย์ ทั้งที่ระบบช้าลงยี่สิบเท่า ระบบเฝ้าระวังที่ดูเฉพาะ error จะไม่เห็นอะไรเลย
• 03วัดก่อนปรับ เราปรับ worker ขึ้นเพราะคิดว่าจะช่วย แล้วพบว่าทำให้แย่ลง การปรับค่าที่ฟังดูสมเหตุสมผลโดยไม่วัดผลก่อนหลัง มีโอกาสทำให้แย่ลงพอ ๆ กับดีขึ้น
• 04กันการเข้าถึงจากภายนอกไว้ตั้งแต่ต้น ในโครงสร้างที่ทดสอบ เครื่องเป็นฝ่ายเปิดการเชื่อมต่อออกไปหา Cloudflare เอง จึงปิดพอร์ตขาเข้าได้ทั้งหมด รวมถึงช่องทางที่ผู้ดูแลใช้ และไม่ได้ทำให้ผลทดสอบด้านความเร็วเปลี่ยนไป
• 05ล็อกเวอร์ชันไว้ให้ทดสอบซ้ำได้ ทุกรอบใช้ image เดียวกันที่ระบุไว้ตายตัว ถ้าไม่ทำแบบนี้เราจะแยกไม่ออกว่าผลที่ต่างกันมาจากการตั้งค่าที่เราเปลี่ยน หรือจากเวอร์ชันที่ขยับเอง

06 โครงสร้างที่ใช้ทดสอบ

07 ค่าโครงสร้างพื้นฐานที่คาดไว้

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

ตารางถัดไปเรียงจากถูกไปแพง เพื่อให้เห็นว่าทางเลือกไหนอยู่ตรงไหน รายการที่เขียนว่าติดตั้งฐานข้อมูลบนเครื่องเอง หมายถึงไม่ใช้บริการฐานข้อมูลแบบจัดการให้ แต่ลง PostgreSQL บนเครื่องอีกตัวหนึ่งแทน

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

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

08 สิ่งที่การทดสอบนี้ยังไม่ได้ตอบ

ข้อจำกัดต่อไปนี้มีผลต่อการตีความผลทดสอบ และต่อขนาดเครื่องที่ควรเลือก

• 01ข้อมูลที่ใช้ทดสอบมีแค่ 8.5 เปอร์เซ็นต์ของของจริง 20,304 ใบสั่งขาย เทียบกับปริมาณเป้าหมาย 238,760 ใบ โครงสร้างข้อมูลสอดคล้องกับของจริง แต่ปริมาณเล็กกว่าราวสิบสองเท่า คำสั่งที่นับจำนวนแถวและรายงานสรุปจะหนักขึ้นตามปริมาณข้อมูล ผลทดสอบกับข้อมูลสองหมื่นใบจึงยังยืนยันไม่ได้ว่าประสิทธิภาพจะอยู่ในระดับเดียวกัน เมื่อมีข้อมูลสองแสนสี่หมื่นใบ
• 02ยังไม่พบจุดที่ระบบใช้งานจริงจะหยุดทำงาน การทดสอบที่ใกล้เคียงการใช้งานจริงที่สุด คือผู้ใช้พร้อมกับตัวเชื่อมที่ยืนยันใบสั่ง (หัวข้อที่ 04) เราดันไปถึง 60 คนเท่านั้น ระบบยังไม่ล้ม แต่ช้าลงชัดเจน จุดที่ระบบชุดนั้นจะหยุดทำงานจึงยังไม่ได้วัด ผลจากหัวข้อ 02 03 และ 04 ชี้ตรงกันว่าน่าจะต่ำกว่า 80 ถึง 100 คนที่วัดได้ตอนไม่มีตัวเชื่อม แต่การชี้ไม่เท่ากับการวัด
• 03ความเร็วและจำนวนตัวเชื่อมเป็นค่าที่เรากำหนดเอง เราใช้ตัวเชื่อมสองตัวที่ตั้งเป้า 200 ใบต่อนาที ซึ่งเป็นสมมติฐาน ไม่ใช่ค่าที่วัดจากระบบจริง ทั้งจำนวนตัวเชื่อมและความถี่ในการเขียน มีผลโดยตรงต่อจำนวนการรอล็อกที่เกิดขึ้น
• 04สต็อกในการทดสอบมีเหลือเฟือ ทุกสินค้ามีจำนวนคงเหลือมากกว่าที่การทดสอบจะใช้หมด การจองสต็อกจึงไม่เคยล้มเหลวหรือถูกแบ่งจอง แคตตาล็อกจริงที่มีสินค้าขายดีเหลือน้อย จะทำให้การรอล็อกกระจุกตัวที่ข้อมูลชุดเล็กลงและรุนแรงขึ้น
• 05เครื่องมือทดสอบของเราขอข้อมูลมากกว่าเบราว์เซอร์จริง เครื่องมือขอจำนวนแถวทั้งหมดในทุกหน้าจอรายการ ขณะที่ตัวโปรแกรมจริงไม่ได้ขอและจำกัดการนับไว้ งานฝั่งฐานข้อมูลในทุกการทดสอบจึงหนักกว่าการใช้งานจริง เวลาตอบสนองที่รายงานไว้ในหน้านี้ จึงเป็นค่าที่แย่กว่าความเป็นจริง และจะแย่กว่ามากขึ้นเมื่อข้อมูลเยอะขึ้น
• 06เราตรวจแล้วว่าการปรับค่าแบบง่ายช่วยไม่ได้ เราทำรายการสิ่งที่น่าจะปรับได้ถูก ๆ แล้วตรวจทีละข้อกับเครื่องจริงก่อนลงมือ ส่วนใหญ่ผู้ให้บริการตั้งมาให้แล้ว หรือยังไม่มีผลที่ปริมาณข้อมูลระดับนี้ หรือเป็นเรื่องของเครื่องมือทดสอบเราเอง ข้อที่เราหวังมากที่สุด คือเชื่อว่ามีค่าตั้งค่าผิดที่ทำให้การพิมพ์ใบแจ้งหนี้เสียเวลาสองวินาทีทุกครั้ง เราวัดโดยตรงแล้วพบว่าไม่จริง เวลานั้นเป็นงานสร้างไฟล์จริง ๆ ไม่มีการตั้งค่าง่าย ๆ ที่ขยับเพดานนี้ได้ เพราะเพดานคือคิวรอแก้ไขข้อมูลสต็อก ซึ่งไม่มีข้อไหนในรายการนั้นแตะถึง
• 07ยังไม่มีตัวเลขผู้ใช้พร้อมกันจากการใช้งานจริง VU ในการทดสอบเป็นค่าที่เรากำหนดเอง ไม่ใช่ค่าที่วัดมาจากระบบที่ใช้งานอยู่ การเทียบ VU กับจำนวนผู้ใช้จริงจึงเป็นการประมาณ และควรยืนยันด้วยข้อมูลการใช้งานก่อนกำหนดขนาดเครื่อง