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

HAProxy ดูเหมือนจะกังวลเกี่ยวกับลูกค้าการเชื่อมต่อและเซิร์ฟเวอร์โดยเฉพาะซึ่ง HAPRoxy จะส่งสัญญาณเตือนหากคุณไม่ได้ทำการตั้งค่าอย่างสมบูรณ์:

While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.

เอกสารไม่ช่วยเหลือในเรื่องนี้มันแสดงให้เห็น "เล็กน้อยเหนือทวีคูณของ 3 วินาที" แต่ไม่ว่าทำไมคุณต้องการเลือกหลาย 1 VS 100 หรือ 42

RPM ที่ฉันใช้ (ที่เก็บ Amazon Linux) ตั้งค่าเริ่มต้นเหล่านี้:

timeout connect         10s
timeout client          1m
timeout server          1m

สองในนั้นคือทวีคูณที่แน่นอน 3 วินาทีโดยละเมิดคำแนะนำอย่างเป็นทางการเดียวที่ฉันเห็น

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

TCP RTO (รับหมดเวลารับ) เริ่มต้นที่สามวินาที ( RFC 1122 ) หากแพ็กเก็ตที่ส่งไม่ได้รับการตอบกลับในเวลานั้นแสดงว่าแพ็กเก็ตที่ส่งนั้นถูกส่งคืน นี่คือสิ่งที่ผู้เขียนอ้างถึง (โปรดทราบว่า RTO ได้รับการปรับขึ้นหรือลงแบบไดนามิกโดยอัลกอริทึมต่างๆนอกขอบเขตของคำถามนี้)

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

สำหรับผู้ใช้เว็บของคุณบางคนอาจมีการเชื่อมต่อเวลาแฝงที่สูงมากเช่นดาวเทียมและอาจสูงกว่าการส่งสัญญาณปกติเนื่องจากสิ่งนี้ RTT ในการเชื่อมต่อที่ใช้งานดาวเทียมอาจเกิน 2000 ms แม้ว่าจะดีทั้งหมดก็ตาม

ทั้งหมดนี้ในใจคุณมักจะต้องการหมดเวลาที่สั้นมากสำหรับคุณและคนที่นานมากสำหรับtimeout connecttimeout client

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

คำนำ

ฉันได้ปรับ HAProxy มาระยะหนึ่งแล้วและทำการทดสอบประสิทธิภาพหลายอย่าง จาก 100 คำร้องขอ HTTP / s ถึง 50 000 คำร้องขอ HTTP / s

คำแนะนำแรกคือการเปิดใช้งานหน้าสถิติ HAProxy คุณต้องการการตรวจสอบไม่มีข้อยกเว้น คุณจะต้องมีการปรับละเอียดหากคุณตั้งใจจะผ่าน 10,000 คำร้องขอ / s

การหมดเวลาเป็นสัตว์ร้ายที่ทำให้เกิดความสับสนเพราะพวกมันมีค่าที่หลากหลายที่เป็นไปได้ส่วนใหญ่ไม่มีความแตกต่างที่สังเกตได้ ฉันยังไม่เห็นสิ่งที่ล้มเหลวเพราะมีจำนวนต่ำกว่า 5% หรือสูงกว่า 5% 10,000 vs 11000 มิลลิวินาทีใครสนใจ? อาจไม่ใช่ระบบของคุณ

องค์ประกอบ

ฉันไม่สามารถใช้ความรู้สึกผิดชอบชั่วดีที่จะให้ตัวเลขสองเท่าเป็น 'หมดเวลาที่ดีที่สุดสำหรับทุกคน'

สิ่งที่ฉันสามารถบอกได้แทนคือการหมดเวลาที่รวดเร็วที่สุดซึ่งยอมรับได้เสมอสำหรับการโหลดบาลานซ์ HTTP (S) หากคุณพบว่าต่ำกว่านี้ก็ถึงเวลากำหนดค่าตัวโหลดบาลานซ์ของคุณใหม่

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

ลูกค้าหมดเวลา:

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

อ่าน : นี่เป็นเวลาสูงสุดในการรับส่วนหัวคำขอ HTTP จากลูกค้า

3G / 4G / 56k / ดาวเทียมอาจช้าในบางครั้ง ถึงกระนั้นพวกเขาควรจะสามารถส่งส่วนหัว HTTP ได้ในเวลาไม่กี่วินาทีไม่ใช่ 30

หากใครบางคนมีการเชื่อมต่อที่แย่มากจนต้องใช้เวลามากกว่า 30 วินาทีในการร้องขอหน้าเว็บ (มากกว่า 10 * 30s เพื่อร้องขอ 10 อิมเมจที่ฝัง / CSS / JS) ฉันเชื่อว่าเป็นที่ยอมรับได้ที่จะปฏิเสธเขา

เซิร์ฟเวอร์ไทม์เอาต์:

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

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

หากเซิร์ฟเวอร์ของคุณช้าจนต้องใช้เวลามากกว่า 30 วินาทีในการเริ่มตอบคำถามจากนั้นฉันเชื่อว่าเป็นเรื่องที่ยอมรับได้หากพิจารณาว่าตาย

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

หมดเวลาเชื่อมต่อ:

ตั้งเวลาสูงสุดเพื่อรอการพยายามเชื่อมต่อกับเซิร์ฟเวอร์ให้สำเร็จ

อ่าน : เวลาสูงสุดที่เซิร์ฟเวอร์ต้องยอมรับการเชื่อมต่อ TCP

เซิร์ฟเวอร์อยู่ใน LAN เดียวกันกับ HAProxy ดังนั้นควรรวดเร็ว ให้เวลาอย่างน้อย 5 วินาทีเพราะนั่นอาจใช้เวลานานเมื่อมีอะไรที่ไม่คาดคิดเกิดขึ้น (แพ็คเก็ต TCP ที่หายไปเพื่อทำการส่งใหม่เซิร์ฟเวอร์จะทำกระบวนการใหม่เพื่อรับคำร้องขอใหม่ขัดขวางการรับส่งข้อมูล)

กรณีพิเศษ : เมื่อเซิร์ฟเวอร์อยู่ใน LAN อื่นหรือผ่านลิงก์ที่ไม่น่าเชื่อถือ การหมดเวลานี้อาจต้องเพิ่มขึ้นเป็นจำนวนมาก (หมายเหตุ: นี่น่าจะเป็นกรณีของสถาปัตยกรรมที่ไม่ดี)

ตรวจสอบการหมดเวลา:

ตั้งค่าการหมดเวลาตรวจสอบเพิ่มเติม แต่หลังจากการเชื่อมต่อได้ถูกสร้างขึ้นแล้ว

ตั้งค่าการตรวจสอบการหมดเวลาเพิ่มเติม แต่หลังจากเชื่อมต่อเรียบร้อยแล้วหากตั้งไว้ haproxy จะใช้ min ("หมดเวลาเชื่อมต่อ", "inter") เป็นการเชื่อมต่อหมดเวลาสำหรับการตรวจสอบและ "หมดเวลาตรวจสอบ" เป็นการหมดเวลาอ่านเพิ่มเติม "min" ถูกใช้เพื่อให้ผู้ใช้ที่มีการ"หมดเวลาเชื่อมต่อ" นานมาก (เช่นผู้ที่ต้องการสิ่งนี้เนื่องจากคิวหรือ tarpit) จะไม่ทำให้เช็คช้าลง (โปรดทราบว่าไม่มีเหตุผลที่ถูกต้องที่จะมีการหมดเวลาเชื่อมต่อที่ยาวนานเช่น "คิวหมดเวลา" และ "timeout tarpit" สามารถใช้เพื่อหลีกเลี่ยงปัญหานั้นได้เสมอ)

อ่าน : เมื่อทำการตรวจสอบสุขภาพเซิร์ฟเวอร์timeout connectจะต้องยอมรับการเชื่อมต่อจากนั้นtimeout checkเพื่อให้การตอบสนอง

เซิร์ฟเวอร์ทั้งหมดต้องมีการตรวจสอบสถานะ HTTP (S) นี่เป็นวิธีเดียวที่ตัวโหลดบาลานซ์จะทราบว่าเซิร์ฟเวอร์พร้อมใช้งานหรือไม่ healthcheck เป็นที่เรียบง่ายหน้าเสมอตอบ/isaliveOK

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

สงครามเรื่อง : ผู้คนจำนวนมากผิดเชื่อว่าเซิร์ฟเวอร์สามารถตอบหน้านี้ง่ายใน 3 มิลลิวินาที พวกเขาตั้งค่าการหมดเวลาใช้งานในระดับสูง (<2000ms) ด้วยการทำงานล้มเหลวขั้นสูง (2 การตรวจสอบล้มเหลว = เซิร์ฟเวอร์ตาย) ฉันเคยเห็นทั้งเว็บไซต์ลงเพราะเหตุนี้ โดยทั่วไปแล้วจะมีปริมาณการใช้งานที่เพิ่มขึ้นเล็กน้อยเซิร์ฟเวอร์แบ็คเอนด์ทำงานช้าลง Healthchecks จะล่าช้า ... จนกระทั่งทันใดนั้นพวกเขาก็หมดเวลาด้วยกัน HAProxy คิดว่าเซิร์ฟเวอร์ทั้งหมดเสียชีวิตในครั้งเดียว