สรุปประสิทธิภาพ ICAP

เอกสารนี้ให้คำแนะนำเกี่ยวกับวิธีที่ Glasswall Halo ICAP server ทำงานในขนาดการปรับใช้ที่แตกต่างกัน ตามที่อธิบายไว้ใน สรุปประสิทธิภาพ.

ขนาดการปรับใช้ที่กำหนดไว้ล่วงหน้าเหล่านี้ช่วยให้องค์กรเข้าใจว่า Halo อาจทำงานได้อย่างไรเมื่อเทียบกับขนาดของการดำเนินงานของตน

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

แนวทางเหล่านี้เป็นกรอบสำหรับการกำหนดความคาดหวังด้านประสิทธิภาพและช่วยประกอบการตัดสินใจในการปรับใช้เบื้องต้น

กรณีการใช้งานการปรับใช้​

กรณีใช้งาน 1: ดาวน์โหลดไฟล์เท่านั้น​

โมเดลนี้ใช้กับองค์กรที่ใช้ Halo ICAP server เฉพาะสำหรับการดาวน์โหลดไฟล์โดยเจตนาเท่านั้น — เช่น เอกสาร ตัวติดตั้ง หรือไฟล์สื่อ ในสถานการณ์นี้ จะส่งต่อไปยัง ICAP server เฉพาะการดาวน์โหลดที่ผู้ใช้ตั้งใจและเป็นผู้เริ่มต้นเท่านั้น ส่วนทรัพยากรเว็บอื่นทั้งหมด (เช่น รูปภาพ สคริปต์ และสไตล์ชีต) จะไม่รวมอยู่ด้วย

จำนวนคำขอต่อวินาทีโดยประมาณ (RPS)​

สมมติว่าผู้ใช้แต่ละรายเริ่มการดาวน์โหลดไฟล์ประมาณ 40 ครั้งต่อวัน การประมาณนี้อ้างอิงจากการสังเกตภายในของ Glasswall

ในการแปลงจำนวนการดาวน์โหลดต่อวันเป็นจำนวนคำขอต่อวินาที:

RPS = 40 downloads per day ÷ 86400 seconds per day ≈ 0.00046

เพื่อความง่าย จึงปัดเป็น 0.00046 RPS ต่อผู้ใช้

หมายเหตุ: "request" หมายถึงการดาวน์โหลดไฟล์ที่ผู้ใช้เป็นผู้เริ่มต้นและถูกสแกนโดยเซิร์ฟเวอร์ ICAP ตัวอย่างเช่น การดาวน์โหลดรายงาน PDF, ไฟล์บีบอัด zip หรือไฟล์ปฏิบัติการ

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

ตัวอย่างผลลัพธ์ด้านประสิทธิภาพ​

การติดตั้งใช้งานขนาดเล็ก

• คลัสเตอร์ Kubernetes แบบโหนดเดียว
• 5 Engines
• 8 Virtual cores
• 28 GB memory

อัตราการประมวลผล: 30 Requests per second (RPS)

ขนาดองค์กรที่เทียบเท่า: ประมาณ 65,000 ผู้ใช้ (กรณีใช้งานการดาวน์โหลดไฟล์)

กรณีใช้งาน 2: การสแกนทราฟฟิกเว็บทั้งหมด​

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

จำนวนคำขอต่อวินาทีโดยประมาณ (rps)​

การประมาณการการใช้งานเว็บอ้างอิงจาก:

• โดยเฉลี่ย หน้าเว็บหนึ่งหน้าต้องใช้ 71 แอสเซ็ต ในการโหลด (http archive 2024)
• ผู้ใช้เข้าชมประมาณ 130 หน้าเว็บต่อวัน (digital silk web statistics)

ซึ่งส่งผลให้ได้:

9230 asset requests per user per day

แปลงเป็น RPS:

RPS = 9230 ÷ 86400 ≈ 0.1068

เพื่อความง่าย จึงปัดเป็น 0.1 RPS ต่อผู้ใช้.

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

ตัวอย่างผลลัพธ์ด้านประสิทธิภาพ​

การติดตั้งใช้งานขนาดเล็ก​

• คลัสเตอร์ Kubernetes แบบโหนดเดียว
• 5 Engines
• 8 Virtual cores
• 28 GB memory

อัตราการประมวลผล: 30 Requests per second (RPS)

ขนาดองค์กรที่เทียบเท่า: ประมาณ 300 ผู้ใช้ (กรณีการใช้งานทราฟฟิกเว็บทั้งหมด)

การปรับใช้ขนาดกลาง​

• คลัสเตอร์ Kubernetes แบบ 3 โหนด
• รวม 15 Engines
• 8 Virtual cores ต่อโหนด (รวม 24)
• หน่วยความจำ 28 GB ต่อโหนด (รวม 84 GB)

ปริมาณงาน: 70 คำขอต่อวินาที (RPS)

ขนาดองค์กรที่เทียบเท่า: ประมาณ 700 ผู้ใช้

การปรับใช้ขนาดใหญ่​

• คลัสเตอร์ Kubernetes แบบ 5 โหนด
• รวม 25 Engines
• 8 Virtual cores ต่อโหนด (รวม 40)
• หน่วยความจำ 28 GB ต่อโหนด (รวม 140 GB)

ปริมาณงาน: 100 คำขอต่อวินาที (RPS)

ขนาดองค์กรที่เทียบเท่า: ประมาณ 1000 ผู้ใช้

สรุป​

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

หากต้องการคำแนะนำโดยละเอียดหรือคำแนะนำด้านการกำหนดขนาดที่ปรับให้เหมาะกับคุณ โปรดติดต่อทีม Glasswall