เฮ้เนื่องจากฉันเป็นผู้เขียนการอ้างอิงนี้ฉันจะตอบกลับ :-)
มีสองประเด็นใหญ่ในไซต์ขนาดใหญ่: การเชื่อมต่อพร้อมกันและเวลาในการตอบสนอง การเชื่อมต่อพร้อมกันเกิดจากไคลเอนต์ที่ช้าซึ่งใช้เวลานานในการดาวน์โหลดเนื้อหาและโดยสถานะการเชื่อมต่อที่ไม่ได้ใช้งาน สถานะการเชื่อมต่อที่ไม่ได้ใช้งานเหล่านี้เกิดจากการใช้การเชื่อมต่อซ้ำเพื่อดึงข้อมูลหลาย ๆ วัตถุหรือที่เรียกว่า keep-alive ซึ่งจะเพิ่มขึ้นตามเวลาแฝง เมื่อไคลเอนต์อยู่ใกล้กับเซิร์ฟเวอร์มากก็สามารถใช้การเชื่อมต่อได้อย่างเข้มข้นและมั่นใจได้ว่าแทบจะไม่มีการใช้งานเลย อย่างไรก็ตามเมื่อลำดับสิ้นสุดลงไม่มีใครสนใจที่จะปิดช่องอย่างรวดเร็วและการเชื่อมต่อยังคงเปิดอยู่และไม่ได้ใช้งานเป็นเวลานาน นั่นเป็นเหตุผลว่าทำไมหลาย ๆ คนจึงแนะนำให้ใช้ระยะเวลาการรักษาชีวิตที่ต่ำมาก ในบางเซิร์ฟเวอร์เช่น Apache ระยะหมดเวลาต่ำสุดที่คุณสามารถตั้งได้คือหนึ่งวินาทีและมักจะมากเกินไปที่จะรองรับการโหลดสูง: หากคุณมีไคลเอนต์ 20000 รายต่อหน้าคุณและพวกเขาดึงข้อมูลโดยเฉลี่ยหนึ่งออบเจ็กต์ทุก ๆ วินาทีคุณจะมีการเชื่อมต่อ 20000 เหล่านั้นอย่างถาวร การเชื่อมต่อพร้อมกัน 20,000 ครั้งบนเซิร์ฟเวอร์เอนกประสงค์เช่น Apache นั้นมีขนาดใหญ่มากโดยจะต้องใช้ RAM ระหว่าง 32 ถึง 64 GB ขึ้นอยู่กับโมดูลที่โหลดและคุณอาจไม่หวังว่าจะสูงขึ้นมากแม้จะเพิ่ม RAM ในทางปฏิบัติสำหรับไคลเอนต์ 20000 คุณอาจเห็นการเชื่อมต่อพร้อมกัน 40000 ถึง 60000 บนเซิร์ฟเวอร์เนื่องจากเบราว์เซอร์จะพยายามตั้งค่าการเชื่อมต่อ 2 ถึง 3 รายการหากมีวัตถุจำนวนมากที่จะดึงข้อมูล และคุณอาจไม่หวังว่าจะสูงขึ้นมากแม้จะเพิ่ม RAM ในทางปฏิบัติสำหรับไคลเอนต์ 20000 คุณอาจเห็นการเชื่อมต่อพร้อมกัน 40000 ถึง 60000 บนเซิร์ฟเวอร์เนื่องจากเบราว์เซอร์จะพยายามตั้งค่าการเชื่อมต่อ 2 ถึง 3 รายการหากมีวัตถุจำนวนมากที่จะดึงข้อมูล และคุณอาจไม่หวังว่าจะสูงขึ้นมากแม้จะเพิ่ม RAM ในทางปฏิบัติสำหรับไคลเอนต์ 20000 คุณอาจเห็นการเชื่อมต่อพร้อมกัน 40000 ถึง 60000 บนเซิร์ฟเวอร์เนื่องจากเบราว์เซอร์จะพยายามตั้งค่าการเชื่อมต่อ 2 ถึง 3 รายการหากมีวัตถุจำนวนมากที่จะดึงข้อมูล
หากคุณปิดการเชื่อมต่อหลังจากแต่ละออบเจ็กต์จำนวนการเชื่อมต่อพร้อมกันจะลดลงอย่างมาก อันที่จริงมันจะลดลงตามปัจจัยที่สอดคล้องกับเวลาเฉลี่ยในการดาวน์โหลดวัตถุตามเวลาระหว่างวัตถุ หากคุณต้องการ 50 ms ในการดาวน์โหลดวัตถุ (ภาพถ่ายขนาดเล็กปุ่ม ฯลฯ ... ) และคุณดาวน์โหลดโดยเฉลี่ย 1 วัตถุต่อวินาทีดังที่กล่าวมาข้างต้นคุณจะมีการเชื่อมต่อเพียง 0.05 ต่อไคลเอนต์ซึ่งมีเพียง 1,000 การเชื่อมต่อพร้อมกันสำหรับ 20000 ไคลเอนต์
ตอนนี้เวลาในการสร้างการเชื่อมต่อใหม่กำลังจะถูกนับ ไคลเอนต์ระยะไกลจะพบกับความล่าช้าที่ไม่พึงประสงค์ ในอดีตเบราว์เซอร์เคยใช้การเชื่อมต่อพร้อมกันจำนวนมากเมื่อปิดใช้งาน Keep-alive ฉันจำตัวเลข 4 ตัวใน MSIE และ 8 บน Netscape ได้ สิ่งนี้จะแบ่งเวลาแฝงเฉลี่ยต่อวัตถุได้มากขนาดนั้น ขณะนี้การรักษาชีวิตมีอยู่ทุกหนทุกแห่งเราไม่เห็นตัวเลขที่สูงขนาดนั้นอีกต่อไปเพราะการทำเช่นนี้จะเพิ่มภาระบนเซิร์ฟเวอร์ระยะไกลและเบราว์เซอร์จะดูแลปกป้องโครงสร้างพื้นฐานของอินเทอร์เน็ต
ซึ่งหมายความว่าด้วยเบราว์เซอร์ในปัจจุบันการได้รับบริการที่ไม่มีการรักษาชีวิตจะตอบสนองได้ดีกว่าบริการที่ยังคงมีชีวิตอยู่ นอกจากนี้เบราว์เซอร์บางตัว (เช่น Opera) ใช้การวิเคราะห์พฤติกรรมเพื่อพยายามใช้ pipelinining การไปป์ไลน์เป็นวิธีที่มีประสิทธิภาพในการใช้ Keep-alive เพราะเกือบจะกำจัดเวลาแฝงด้วยการส่งคำขอหลายครั้งโดยไม่ต้องรอการตอบกลับ ฉันได้ลองใช้กับหน้าเว็บที่มีรูปภาพขนาดเล็ก 100 รูปและการเข้าถึงครั้งแรกเร็วกว่าปกติประมาณสองเท่า แต่การเข้าถึงครั้งต่อไปเร็วกว่าประมาณ 8 เท่าเนื่องจากการตอบกลับมีขนาดเล็กมากจนนับเฉพาะเวลาแฝง (เท่านั้น "304" คำตอบ)
ฉันจะบอกว่าตามหลักการแล้วเราควรมี Tunables บางอย่างในเบราว์เซอร์เพื่อให้การเชื่อมต่อมีชีวิตอยู่ระหว่างวัตถุที่ดึงมาและวางลงทันทีเมื่อหน้าเสร็จสมบูรณ์ แต่เราไม่เห็นว่าน่าเสียดาย
ด้วยเหตุนี้ไซต์บางแห่งที่จำเป็นต้องติดตั้งเซิร์ฟเวอร์สำหรับวัตถุประสงค์ทั่วไปเช่น Apache ที่ด้านหน้าและต้องรองรับไคลเอนต์จำนวนมากโดยทั่วไปจะต้องปิดการใช้งาน Keep-alive และเพื่อบังคับให้เบราว์เซอร์เพิ่มจำนวนการเชื่อมต่อพวกเขาใช้ชื่อโดเมนหลายชื่อเพื่อให้การดาวน์โหลดสามารถขนานกันได้ เป็นปัญหาโดยเฉพาะอย่างยิ่งในไซต์ที่ใช้ SSL อย่างเข้มข้นเนื่องจากการตั้งค่าการเชื่อมต่อจะสูงขึ้นเนื่องจากมีการเดินทางไปกลับเพิ่มเติมอีกหนึ่งครั้ง
สิ่งที่สังเกตได้บ่อยกว่าในปัจจุบันคือไซต์ดังกล่าวชอบติดตั้งส่วนหน้าแบบเบาเช่น haproxy หรือ nginx ซึ่งไม่มีปัญหาในการจัดการการเชื่อมต่อพร้อมกันนับสิบถึงหลายแสนครั้งพวกเขาเปิดใช้งาน Keep-alive บนฝั่งไคลเอ็นต์และปิดการใช้งานบน ด้าน Apache ในด้านนี้ค่าใช้จ่ายในการสร้างการเชื่อมต่อแทบจะเป็นค่าว่างในแง่ของ CPU และไม่สามารถสังเกตได้เลยในแง่ของเวลา ด้วยวิธีนี้จะให้สิ่งที่ดีที่สุดสำหรับทั้งสองโลก: เวลาแฝงที่ต่ำเนื่องจากการรักษาชีวิตด้วยระยะหมดเวลาที่ต่ำมากในฝั่งไคลเอ็นต์และจำนวนการเชื่อมต่อที่ต่ำในฝั่งเซิร์ฟเวอร์ ทุกคนมีความสุข :-)
ผลิตภัณฑ์เชิงพาณิชย์บางอย่างปรับปรุงสิ่งนี้เพิ่มเติมโดยใช้การเชื่อมต่อระหว่างตัวโหลดบาลานซ์ด้านหน้าและเซิร์ฟเวอร์ซ้ำและการเชื่อมต่อไคลเอ็นต์ทั้งหมดผ่านทางมัลติเพล็กซ์ เมื่อเซิร์ฟเวอร์อยู่ใกล้กับ LB การได้รับจะไม่สูงกว่าโซลูชันก่อนหน้ามากนัก แต่มักจะต้องมีการปรับเปลี่ยนแอปพลิเคชันเพื่อให้แน่ใจว่าไม่มีความเสี่ยงที่เซสชันจะข้ามระหว่างผู้ใช้เนื่องจากการแชร์การเชื่อมต่อระหว่างผู้ใช้หลายคนโดยไม่คาดคิด . ในทางทฤษฎีสิ่งนี้ไม่ควรเกิดขึ้น ความเป็นจริงมันแตกต่างกันมาก :-)