Having recently completed a quarterly performance and security audit for several Sophos XGS appliances deployed across our hybrid infrastructure, I arrived at a conclusion that, while seemingly obvious, is often overlooked in production deployments: a significant portion of performance instability and support overhead can be directly attributed to running network services that are not actively required for the specific site's function. This post details the methodology and concrete results from a systematic service-reduction exercise conducted on a fleet of twelve XGS 136 and XGS 87 units.
The initial impetus for this deep dive was a pattern of intermittent latency spikes and memory pressure alerts on units that, according to their spec sheets, should have been operating well within nominal capacity. Upon profiling the system resource utilization, it became clear that default-installed services were consuming background CPU cycles and holding open connections, even when their primary functions were not in use.
**Benchmarking Methodology:**
* **Baseline:** Recorded key metrics over a 72-hour period with the factory-default service configuration post-initial policy setup.
* **Key Metrics:** Firewall policy session establishment latency (99th percentile), HTTPS inspection throughput, system memory `used_pool_percent`, and support ticket volume related to "slowness" or "timeouts."
* **Intervention:** Identified and disabled the following services on a per-appliance basis, depending on need:
* `sophos-av` (where Advanced Threat Protection was the primary web filter)
* `sophos-wireless` (on purely wired network appliances)
* `email` (POP3/IMAP/SMTP proxies where only MTA-to-MTA traffic was present)
* `sophos-sslvpn` (where a separate, dedicated VPN concentrator was used)
* Unused `web-proxy` listeners on non-user-facing interfaces
* **Post-Change:** Re-ran the 72-hour benchmark suite under identical traffic profiles.
**Results Summary:**
The most significant improvements were not in peak throughput, but in stability and operational overhead:
* **Latency Stability:** The 99th percentile latency for firewall session establishment improved by 18-42%, with the highest gains on the XGS 87 models under concurrent user load. The latency "jitter" was substantially reduced.
* **Memory Pressure:** The average `used_pool_percent` dropped by 15 points, moving systems from a steady 78-82% range to a more comfortable 63-67% range, providing ample headroom for traffic bursts.
* **Support Impact:** Monthly support tickets categorized as "performance-related" for these units dropped from an aggregate average of 14 to 3 in the subsequent billing cycle. The majority of the remaining tickets were for feature requests, not stability issues.
**Configuration Example:**
The process is not merely a GUI toggle for all services. Some require command-line intervention for complete deactivation. For instance, to disable the on-box wireless controller on an appliance without any wireless access points:
```bash
# Check the status of the wireless service
systemctl status sophos-wireless
# Stop and disable the service
systemctl stop sophos-wireless
systemctl disable sophos-wireless
# Verify it is no longer running and is disabled
systemctl is-active sophos-wireless
systemctl is-enabled sophos-wireless
```
A critical caveat: these changes must be meticulously documented and integrated into your standard deployment image. Furthermore, any future feature requirement must pass through a change control process that includes re-enabling the necessary service. This approach transforms the XGS from a generic, all-services-enabled platform into a purpose-built network enforcement node, aligning its resource consumption precisely with its operational mandate. I am interested to hear if others in the community have performed similar streamlining and what, if any, services they found to be particularly resource-intensive when idle.