VM และเบราว์เซอร์บนคลาวด์คิดค่าบริการตามเวลา งานแบบแบตช์จึงชนโควตาได้ง่าย ควรประเมินการใช้ทรัพยากร กำหนดเพดานงานพร้อมกันที่ใช้งานได้จริง และแก้ปัญหาตามลำดับเมื่อเกินโควตา
สำหรับทรัพยากรที่คิดค่าบริการตามเวลา หลักการคิดเงินตรงไปตรงมา: ระยะเวลาทำงานคูณจำนวนอินสแตนซ์ โควตาคือเพดานแบบตายตัว เมื่อชนเพดานแล้ว งานไม่ได้แค่ช้าลง แต่ล้มเหลวทันที—สร้างอินสแตนซ์ใหม่ไม่ได้ อินสแตนซ์ที่กำลังทำงานอาจถูกเรียกคืน และ API เริ่มตอบกลับด้วยข้อผิดพลาดจากการจำกัดอัตรา การรู้ว่าคุณเหลือระยะห่างจากเพดานเท่าไรมีประโยชน์กว่าการเพิ่มงบหลังเกิดปัญหา
แยกก่อนว่าการใช้งานใดจำเป็นจริง
โควตาเท่ากันอาจสร้างผลลัพธ์ต่างกันมาก ขึ้นอยู่กับว่านำไปใช้กับงานใด เริ่มจากสำรวจงานทั้งหมดแล้วแยกตามว่าจำเป็นต้องทำแบบเรียลไทม์จริงหรือไม่
งานที่เปิดค้างตลอดเป็นกลุ่มที่กินโควตาได้ง่ายที่สุด แม้จะทำงานจริงเพียงไม่กี่นาทีแต่เปิดอยู่ทั้งวัน การเปลี่ยนจากการเฝ้าติดตามตลอดเวลาเป็นการทริกเกอร์ตามตาราง มักลดการใช้ทรัพยากรได้มากโดยแทบไม่กระทบธุรกิจ งานที่พุ่งสูงในช่วงเวลาหนึ่งสามารถย้ายเวลาได้ ส่วนงานครั้งเดียวให้เริ่มเมื่อจำเป็นเท่านั้น
จากนั้นถามตัวเองว่า หากงานนี้ทำช้าลงหกชั่วโมง ธุรกิจจะได้รับผลกระทบหรือไม่ หากกระทบ ให้คงไว้ในเส้นทางสำคัญและทำแบบเรียลไทม์ หากไม่กระทบ ให้เปลี่ยนเป็นงานแบตช์ลำดับความสำคัญต่ำและย้ายไปช่วงที่โควตาว่างกว่า การติดตามราคาคู่แข่งจากทุกชั่วโมงเป็นวันละสองครั้ง ในหลายกรณีไม่ได้ลดคุณค่าของข้อมูลอย่างมีนัยสำคัญ
ประเมินการใช้และกำหนดงานพร้อมกันอย่างไร
เมื่อคิดค่าบริการตามเวลาการทำงานของอินสแตนซ์ การใช้รวมของงานหนึ่งชุดโดยประมาณเท่ากับเวลาทำงานเฉลี่ยของหนึ่งงานคูณจำนวนงาน ไม่ได้ขึ้นอยู่กับว่าจะเปิดงานพร้อมกันมากเพียงใด งานพร้อมกันมีผลเพียงว่าชุดงานจะเสร็จเร็วแค่ไหน สิ่งที่เกี่ยวกับงานพร้อมกันโดยตรงคือแรงกดดันชั่วขณะ: ยิ่งมีอินสแตนซ์เริ่มพร้อมกันมาก ก็ยิ่งมีโอกาสชนเพดานงานพร้อมกันของพูลทรัพยากรหรือการจำกัดอัตราของแพลตฟอร์ม
ดังนั้นให้เริ่มจากจำนวนงานพร้อมกันต่ำที่สุด ก่อนอื่นรันหนึ่งงานเพื่อตรวจสอบเวลาทำงานเฉลี่ยและอัตราสำเร็จ จากนั้นค่อยเพิ่มเป็นไม่กี่งาน แล้วเป็นราวสิบกว่างาน พร้อมบันทึกอัตราล้มเหลวและจำนวนการลองใหม่ เมื่อผ่านจุดหนึ่งแล้วอัตราล้มเหลวเพิ่มขึ้นชัดเจน จุดนั้นคือเพดานที่ใช้งานได้จริง เพิ่มต่อไปก็เพียงเสียเวลาที่ประหยัดได้คืนไปกับการลองใหม่
ตอนประเมินอย่าลืมเวลาที่มองไม่เห็น เช่น การรอเข้าสู่ระบบ การโหลดหน้า ขั้นตอนยืนยัน และการลองใหม่หลังล้มเหลว สิ่งเหล่านี้มักใช้เวลานานกว่ากระบวนการหลักเสียอีก การเผื่อเวลาให้แต่ละงานมีประโยชน์กว่าการคำนวณให้เป๊ะเป็นนาที
เมื่อโควตาหมดจะมีลักษณะอย่างไร
ภาวะโควตาหมดอาจสังเกตได้ยาก เพราะมักดูเหมือนปัญหาอื่น
อาการหนึ่งคืองานค้างตั้งแต่ช่วงเริ่มต้น เพราะคำขอสร้างสภาพแวดล้อมหรืออินสแตนซ์ถูกปฏิเสธ และในล็อกเหลือเพียงข้อความล้มเหลวที่ไม่ชัดเจน อีกแบบคืออินสแตนซ์ถูกเรียกคืนระหว่างทำงาน ทำให้ความคืบหน้าก่อนหน้าสูญเปล่า นอกจากนี้ยังอาจพบข้อผิดพลาดจากการจำกัดอัตรา บางงานสำเร็จบางงานล้มเหลว หรือคิวที่ยาวขึ้นเรื่อย ๆ แต่ไม่มีการประมวลผล
สิ่งที่วินิจฉัยผิดได้ง่ายที่สุดคืออาการค้างหลอก: อินสแตนซ์ยังอยู่และงานดูเหมือนกำลังทำงาน แต่จริง ๆ แล้วติดอยู่ในสถานะรอ ขณะที่โควตายังคงถูกใช้ตามเวลา หากเจอแบบนี้ ให้ดูแผงการใช้โควตาก่อน แล้วลองงานเล็กหนึ่งงานแยกต่างหาก หากงานเล็กก็เริ่มไม่ได้ ให้ตรวจสอบโควตาหรือสิทธิ์ หากทำงานปกติ ปัญหาน่าจะอยู่ที่จำนวนงานพร้อมกันหรือการนำสภาพแวดล้อมกลับมาใช้ซ้ำ
ลำดับการแก้ไข
เริ่มจากสิ่งที่ไม่ต้องเสียเงินเพิ่ม
ขั้นแรก หยุดการใช้งานแบบค้างตลอดที่มีคุณค่าต่ำ และเปลี่ยนงานเฝ้าติดตามเป็นแบบตามตาราง ขั้นที่สอง ย้ายงานที่รอได้ไปยังช่วงที่โควตาว่างกว่า เพื่อทำให้เส้นการใช้ทรัพยากรราบลง ขั้นที่สาม ลดเพดานงานพร้อมกันและเพิ่มคิว เพื่อให้งานถูกประมวลผลตามความจุที่มีอยู่แทนที่จะเริ่มพร้อมกันทั้งหมด ขั้นที่สี่ ลดการใช้ที่สูญเปล่า: แคชทรัพยากรเดิมแทนการดึงซ้ำ ดึงข้อมูลให้มากขึ้นต่อคำขอเมื่อเหมาะสม ยุติคำขอที่แน่นอนว่าจะล้มเหลวอย่างรวดเร็ว และอย่าลองใหม่ไม่สิ้นสุด
หลังทำครบสี่ขั้นตอนแล้ว จึงค่อยพิจารณาว่าจำเป็นต้องเพิ่มงบหรือขยับไปแพ็กเกจระดับสูงกว่าหรือไม่ บ่อยครั้งจะพบว่าโควตาที่ต้องใช้จริงน้อยกว่าที่คิดไว้ตอนแรก ในทางกลับกัน หากเพิ่มงบก่อน เท่ากับจ่ายให้กับนิสัยการใช้งานที่ไม่มีประสิทธิภาพไปด้วย
อย่าบีบชั้นสภาพแวดล้อมไปพร้อมกับชั้นประมวลผล
ข้อผิดพลาดที่พบบ่อยเมื่อประหยัดโควตาคือให้หลายงานใช้สภาพแวดล้อมเบราว์เซอร์เดียวกัน โดยคิดว่าเปิดสภาพแวดล้อมครั้งเดียวก็พอ
ผลเสียเกิดขึ้นทันที: เซสชันทับกัน สถานะการเข้าสู่ระบบถูกแทนที่ แคชปะปนกัน และความล้มเหลวของงานหนึ่งอาจลากงานอื่นให้ล้มตาม เวลาของอินสแตนซ์ที่ประหยัดได้เพียงเล็กน้อยจะถูกใช้คืนหลายเท่าในการแก้ปัญหาและรันงานใหม่
ควรมองสองชั้นนี้แยกกัน ชั้นประมวลผลทำหน้าที่รันตรรกะของงาน จัดตารางตามความต้องการ และเน้นประสิทธิภาพด้านต้นทุน ส่วนชั้นสภาพแวดล้อมดูแลตัวตนและการแยกออกจากกัน โดยให้แต่ละงานมีสภาพแวดล้อมอิสระเพื่อเน้นความเสถียร การบีบชั้นสภาพแวดล้อมเพราะทรัพยากรประมวลผลตึงตัวคือการปะปนต้นทุนสองประเภท การสร้างและเรียกคืนสภาพแวดล้อมจำนวนมากควรจัดการแบบรวมศูนย์ด้วยเครื่องมือของชั้นสภาพแวดล้อม เมื่อ PurpleMark แยกเซสชันและแคชตามสภาพแวดล้อม งานและตัวประมวลผลในชั้นบนจึงจัดตารางได้ยืดหยุ่นกว่า
ข้อเตือนใจสุดท้าย: อย่าลดต้นทุนด้วยวิธีที่ละเมิดกฎ อย่าใช้บริการจากช่องทางที่ไม่เป็นทางการเพียงเพื่อประหยัดโควตา และอย่าพยายามฝืนเพิ่มปริมาณงานด้วยการเพิ่มความถี่ของคำขอ เมื่อการจำกัดอัตราทำงานแล้ว การลองซ้ำมักกินโควตามากกว่าการทำงานด้วยจังหวะที่ควบคุมได้
