จำนวนการทำงานพร้อมกันที่คุณสามารถใส่ในใบเสนอราคาได้

จำนวนการทำงานพร้อมกันที่คุณสามารถใส่ในใบเสนอราคาได้.

การกำหนดจำนวนการทำงานพร้อมกันและขีดจำกัดอัตราการส่ง

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

การผูกหน้าต่างจำกัดอัตราเข้ากับใบเสนอราคาของผู้ซื้อ

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

JIT และการระงับยอดเงินคงเหลือแบบเติมเงินสำหรับหมายเลข E.164

เราไม่ได้รักษาคลังหมายเลขที่ไม่ได้ใช้งานแบบคงที่ แต่ IOSOR ใช้โมเดลการจัดสรรหมายเลขแบบ Just-In-Time (JIT) ที่ยืดหยุ่น เมื่อผู้ซื้อร้องขอทรัพยากร E.164 ใหม่ แพลตฟอร์มจะทำการค้นหาแบบ JIT และทำการระงับยอดเงินคงเหลือแบบเติมเงินในบัญชีแยกประเภทสำหรับ MRC ที่เกี่ยวข้อง และกำหนดหมายเลขที่ใช้งานได้ทันที วิธีนี้จะช่วยลดค่าใช้จ่ายที่ไม่จำเป็น และช่วยให้มั่นใจได้ว่าคุณจะจ่ายเฉพาะสินทรัพย์ที่สร้างรายได้และใช้งานอยู่เท่านั้น

เกณฑ์ทางการเงินและการตรวจสอบเบื้องต้น

การดำเนินงาน CPaaS แบบไวท์เลเบลต้องมีการควบคุมบัญชีแยกประเภทที่เข้มงวด บัญชีใหม่ต้องมียอดเงินเติมเงินขั้นต่ำ USD 20 เพื่อเริ่มส่งทราฟฟิกจริง เมื่อผู้ซื้อขยายปริมาณ SMS และ OTP ค่าใช้จ่ายรายเดือนของพวกเขาจะเพิ่มขึ้น เมื่ออัตราการใช้งานของผู้ซื้อเข้าใกล้การตรวจสอบเบื้องต้นที่ประมาณ USD 1,000/เดือน แพลตฟอร์มจะเปิดใช้งานการแจ้งเตือนอัตโนมัติเพื่อตรวจสอบขีดจำกัดการทำงานพร้อมกันของพวกเขา และตรวจสอบว่าโปรไฟล์การกำหนดเส้นทางของพวกเขาได้รับการปรับให้เหมาะสมสำหรับการส่งข้อมูลความจุสูง

การส่ง Webhook และขั้นตอนการทำงานของ DLR

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

บทความที่เกี่ยวข้อง: คิวจำกัด TPS — ไม่มีการทิ้งข้อความแบบเงียบๆ · ความจุ TPS กับพฤติกรรมการดำเนินงานด้านปริมาณ · การกันยอดเติมเงินก่อนการหักครั้งแรก.

เริ่มต้นกับ IOSOR

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

สรุป IOSOR

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

กำหนดหน้าต่างอัตราการส่งที่ชัดเจนในคอนโซลก่อนลงนามใบเสนอราคาของลูกค้าปริมาณมาก อย่าเสนออัตราการส่งที่ไม่จำกัดหรือเพิกเฉยต่อความจุในการรับเว็บฮุก DLR ของผู้ซื้อเมื่อให้คำมั่นสัญญาเกี่ยวกับ SLA การทำงานพร้อมกัน