ICAP Performance Summary

This document provides guidance on how Glasswall Halo ICAP Server performs across different deployment sizes, as detailed in the Performance Summary.

These predefined deployment sizes help organizations understand how Halo may perform relative to the scale of their operations.

While the three example configurations serve as helpful benchmarks, Halo is highly scalable. It can be deployed to meet a wide range of performance and capacity requirements, provided sufficient compute resources and budget are available.

These guidelines offer a framework for setting performance expectations and informing initial deployment decisions.

Deployment Use Cases

Use Case 1: File Downloads Only

This model applies to organizations using the Halo ICAP server exclusively for intentional file downloads—such as documents, installers, or media files. In this scenario, only deliberate, user-initiated downloads are forwarded to the ICAP server. All other web assets (like images, scripts, and stylesheets) are excluded.

Estimated Requests Per Second (RPS)

Each user is assumed to initiate approximately 40 file downloads per day. This estimate is based on internal Glasswall observations.

To convert daily downloads to requests per second:

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

For simplicity, this is rounded to 0.00046 RPS per user.

Note: A "request" refers to a user-initiated file download that is scanned by the ICAP server. Examples include downloading a PDF report, a ZIP archive, or an executable file.

These figures are conservative. Actual usage may vary depending on automation scripts, scheduled downloads, or user behavior. If your environment involves automated systems or frequent batch downloads, adjust your calculations accordingly.

Example Performance Result

Small Deployment

• Single node Kubernetes cluster
• 5 Engines
• 8 virtual cores
• 28 GB Memory

Throughput:
30 Requests per Second (RPS)

Equivalent Organization Size:
Approximately 65,000 users (file download use case)

Use Case 2: All Web Traffic Scanning

In this model, the Halo ICAP server scans all web traffic, not just deliberate downloads. This assumes a proxy on the user’s browser or machine forwards all web requests to the ICAP server.

Estimated Requests Per Second (RPS)

Web usage estimates are based on:

• Average web page requires 71 assets to load (HTTP Archive 2024)
• Users visit around 130 web pages per day (Digital Silk Web Statistics)

This results in:

9230 asset requests per user per day

Converting to RPS:

RPS = 9230 ÷ 86400 ≈ 0.1068

For simplicity, this is rounded to 0.1 RPS per user.

Note: This calculation does not account for browser caching, which could significantly reduce load on the ICAP server. Since reliable cache hit rate data is not available, these estimates assume no caching. Actual system load may be lower in practice.

Example Performance Results

Small Deployment

• Single node Kubernetes cluster
• 5 Engines
• 8 virtual cores
• 28 GB Memory

Throughput:
30 Requests per Second (RPS)

Equivalent Organization Size:
Approximately 300 users (all web traffic use case)

Medium Deployment

• 3 node Kubernetes cluster
• 15 Engines total
• 8 virtual cores per node (24 total)
• 28 GB Memory per node (84 GB total)

Throughput:
70 Requests per Second (RPS)

Equivalent Organization Size:
Approximately 700 users

Large Deployment

• 5 node Kubernetes cluster
• 25 Engines total
• 8 virtual cores per node (40 total)
• 28 GB Memory per node (140 GB total)

Throughput:
100 Requests per Second (RPS)

Equivalent Organization Size:
Approximately 1000 users

Summary

These deployment examples offer a starting point for sizing your Glasswall Halo ICAP Server deployment, whether you are scanning specific file downloads or all web traffic. Performance can be tuned to meet specific needs by scaling horizontally or vertically as required.

For detailed guidance or tailored sizing advice, contact the Glasswall team.