haproxy: รักษาเซสชันที่มีอยู่ภายใต้โหลดสูงให้บริการ '503' กับการมาถึงใหม่


12

พยายามทำสิ่งที่กล่าวไว้ในชื่อ: รักษาเซสชันที่มีอยู่ภายใต้โหลดสูงและให้บริการข้อความ 503 ข้อความแก่ผู้เยี่ยมชมที่เพิ่งมาถึง

ปัญหา: ใช้งานได้ แต่เซสชันไม่เกินกว่าประมาณ 90 วินาที

ผลลัพธ์ปัจจุบันทำให้ฉันสงสัยว่ามีการตั้งค่าการหมดเวลาหรือไม่ฉันหายไป

วัตถุประสงค์

ฉันพยายามรับ haproxy ไปที่:

  • ส่งคำขอสำหรับเซสชันใหม่ไปที่แบ็กเอนด์ -001 เมื่อจำนวนเซสชันทั้งหมดในส่วนหน้าต่ำกว่าเกณฑ์ที่กำหนด
  • ทำหน้าที่ข้อผิดพลาด 503 ครั้งเพื่อเซสชันใหม่เมื่อจำนวนเซสชันทั้งหมดในส่วนหน้ามากกว่าขีด จำกัด นั้น
  • อนุญาตการร้องขอสำหรับเซสชันที่มีอยู่แม้ว่าจำนวนเซสชันเกินขีด จำกัด

ด้วยวิธีนี้ผู้เยี่ยมชมที่อยู่ในระหว่างการกรอกแบบฟอร์มหลายขั้นตอนจะไม่ประหลาดใจกับข้อผิดพลาด 503 และผู้เยี่ยมชมใหม่สามารถบอกได้ว่า "โปรดกลับมาใหม่ในภายหลังเพราะเราไม่ว่างจริงๆ"

ติดตั้ง

การตั้งค่ามีดังนี้:

            {visitors}
                ↓ 
            [haproxy]
                ↓ 
[rails app on unicorn served by nginx]   (right now just one 
                                            backend: 'backend-001')

แนวทางปัจจุบัน

เพื่อให้บรรลุตามข้างต้นฉันใช้การตั้งค่าด้านล่าง

อันนี้สำหรับการทดสอบที่มีขีด จำกัด ต่ำมาก (10 การเชื่อมต่อบน front-end (fe_conn gt 10)) เพื่อให้การทดสอบง่ายขึ้น

เพื่อให้เซิร์ฟเวอร์ทำงานหนักฉันกำลังใช้ httperf ดังนี้:

httperf - ฮอก - เซิร์ฟเวอร์ staging.machine.tld --uri / do_some_things --wsess = 500,10,30 - อัตรา 2

global
    daemon
    maxconn 10000

defaults
    mode        http
    timeout connect 6s
    timeout client  60s
    timeout server  60s
    balance roundrobin
    option http-server-close

frontend http-in
    bind [PUBLIC_IP]:80

    default_backend backend-001

    acl too_many fe_conn gt 10
    use_backend b_too_many if too_many

backend backend-001
    fullconn 10
    appsession _session_id len 128 timeout 7200s

    cookie SERVERID insert maxidle 7200s
    server Server1 127.0.10.1:80 cookie backend-001 check

backend b_too_many
    errorfile 503 /var/www/50x.html

ปัญหา

ดังที่ได้กล่าวไว้ข้างต้นปัญหาคือ: มันใช้งานได้เกือบ แต่เซสชันไม่นานเกินกว่า 90 วินาที

หากคุณคลิกต่อไปคุณจะยังคงเซสชันของคุณแม้ในขณะที่ไม่ว่าง 10 เซสชัน

การพยายามเปิดหน้าเว็บบนเซิร์ฟเวอร์ที่มีอินสแตนซ์ของเบราว์เซอร์อื่นทำให้คุณได้รับข้อผิดพลาด 503

ดังนั้นดูเหมือนว่าฉันเกือบจะอยู่ที่นั่น ไม่มีใครมีความคิดว่าสิ่งใดที่อาจทำให้เกิดเซสชั่นสั้น ๆ ?

และโดยเฉพาะอย่างยิ่งฉันสามารถแก้ไขได้ :)

(แก้ไข: นำ 'น้ำหนัก 1 maxconn 10' ออกจาก 'เซิร์ฟเวอร์' บรรทัดไม่เกี่ยวข้องและอาจทำให้สับสน) (แก้ไขลำดับที่ 2: แก้ไข '10 เซสชันที่ส่วนหน้า 'เป็น '10 การเชื่อมต่อที่ส่วนหน้า')


อาจเป็นคำถามที่งี่เง่า - การตั้งค่า keep_alive ใน nginx คืออะไร เห็นได้ชัดว่ามันเป็น 75s โดยค่าเริ่มต้น - นั่นอาจเป็นปัญหาหรือไม่
Aidan Kane

คำตอบ:


4

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

90 วินาทีที่คุณสังเกตเห็นแน่นอนว่าเบราว์เซอร์จะหยุดพักชั่วคราวเพื่อการเชื่อมต่อที่ไม่ได้ทำงาน

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

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


1
ขอบคุณ! ที่เคลียร์ขึ้นเยอะมาก ตอนนี้ฉันได้ทำงานโดย (ในสิ่งอื่น ๆ ) การตรวจสอบแบ็กเอนด์คุกกี้ด้วย hdr_sub (ดังนั้น "hdr_sub (คุกกี้) SERVERID = แบ็กเอนด์ -001") ฉันจะโพสต์กำหนดค่าการทำงานเมื่อเสร็จแล้ว
Apenootje
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.