การจำกัดอัตราการใช้งาน

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

การจำกัดจำนวนตาม IP และ บัญชีผู้ใช้:

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

หมายเหตุ: เราจำกัดจำนวนการสร้าง token บน Vault ไว้ค่อนข้างต่ำเมื่อเปรียบเทียบกับ API หลัก

การลำดับความสำคัญของประเภทคำสั่ง:
คำสั่งทั้งหมดจะถูกจัดลำดับด้วยวิธีการดังนี้:

1. คำสั่ง POST/PUT ในโหมดใช้งานจริง (ตัวอย่างเช่น การสร้างรายการรับชำระเงิน, การตัดวงเงิน และการคืนเงิน)
2. คำสั่ง GET ในโหมดใช้งานจริง (ตัวอย่างเช่น การเรียกดูรายการ, การดึงข้อมูลรายการ)
3. คำสั่งในโหมดทดสอบทั้งหมด

ข้อขัดข้อง

หากพบว่า API ตอบกลับการเรียกใช้งานด้วย HTTP 429 “Too May Requests” หมายถึงว่าร้านค้ามีการส่งคำสั่งเข้ามายัง Opn Payments เป็นจำนวนมาก และใกล้ถึงจำนวนสูงสุดที่เรากำหนดไว้แล้ว หากนโยบายการทำงานนี้ส่งผลกระทบต่อการดำเนินงานของร้านค้า สามารถส่งอีเมลถึงทีมงานของเรา

การทดสอบระบบ (load testing)

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

ด้วยเหตุผลเหล่านี้เราจึงไม่สนับสนุนให้ร้านค้าทำ “load test” หรือวัด “benchmark” ใดๆ กับ API ของเรา เช่น วัดการตอบสนองของระบบโดยสร้างปริมาณการใช้งานจำนวนมากๆ ก่อนจัดโปรโมชันพิเศษ เป็นต้น เนื่องจากผลลัพธ์ที่ได้จะไม่แม่นยำ

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

วิธีหลีกเลี่ยงการถูกจำกัดใช้งาน

• หลีกเลี่ยงการตรวจสอบข้อมูลด้วยวิธี polling และไปใช้งาน webhooks แทน
• หลีกเลี่ยงการส่งคำสั่งจำนวนมากๆ พร้อมกันในคราวเดียว เราแนะนำให้กระจายคำสั่งออกเป็นจำนวนที่ย่อยลงมา เช่น จากการส่งคำสั่ง 100 ครั้งใน 1 วินาที ให้กระจายออกเป็น 100 ครั้งใน 5 วินาที หรือ 20 คำสั่งต่อวินาที
• หลีกเลี่ยงการให้ทีมงานเกิน 10 คนระดมส่งคำสั่งเข้ามาที่ API ของเราพร้อมๆ กัน
• หากคาดการณ์แล้วว่าจะมีการเรียกใช้งาน API ของเราจำนวนมากๆ กรุณาแจ้งทีมงานของเราล่วงหน้า