Black Duck SCA Hardware Scaling Guidelines

How was the data gathered?

The performance data below was gathered using Black Duck SCA 2025.4.1 with SCASS integration for Package Manager and Signature scans (default). Workload for deriving the Resource Guidance values includes the workload used by majority of our customer like Signature Scans, Package Manager Scans, Reports, SBOM Exports, and Policy Overrides.

SPH values are calculated using a mix of Signature scans, Package Manager detector scans. Average scan sizes vary from customer to customer so exact SPH throughput is highly customer specific. These metrics were gathered from Google Cloud Platform, which provides different database read/write IOPS for different configurations

How to interpret the Hardware Scaling Guidelines table

The SPH values represent the maximum sustained or regular load on the Black Duck SCA system. Although spikes exceeding normal scan load can be handled by the system, customers should avoid regularly exceeding the SPH scan capacity of their Black Duck SCA configuration. In addition, if customers exceed either the project version count or API calls per hour they should upsize their instance to support their required project version count and API usage.

Black Duck SCA project version usage data is available in the Black Duck SCA UI by navigating to Admin > System Information > usage: project.

Black Duck does not currently track all API statistics, and so these values are obtained from the external services which interact with and call Black Duck SCA APIs.

Note: The 10sph configuration found in the sizing-gen0x folder is intended solely as a base configuration for testing purposes. It is not recommended nor supported for production deployment.

Table 1. Hardware Scaling Guidelines
Name	Details		GEN04 to GEN05 Resource Comparison
120sph	Scans/Hour: 120 SPH % Increase: 0% APIs/Hour: 4,500 Project Versions: 27,000	IOPS: Read: 15,000 / Write: 15,000 Black Duck SCA Services: CPU: 7 core / Memory: 38 GB PostgreSQL: CPU: 4 core / Memory: 16 GB Total: CPU: 11 core / Memory: 54 GB	Black Duck SCA Services: CPU: 11 → 7 core (24% improvement) Memory: 56 → 38 GB (25% improvement)
250sph	Scans/Hour: 300 SPH % Increase: 20% APIs/Hour: 9,000 Project Versions: 21,000	IOPS: Read: 15,000 / Write: 15,000 Black Duck SCA Services: CPU: 8 core / Memory: 47 GB PostgreSQL: CPU: 6 core / Memory: 24 GB Total: CPU: 14 core / Memory: 71 GB	Black Duck SCA Services: CPU: 16 → 8 core (33% improvement) Memory: 86 → 47 GB (35% improvement)
500sph	Scans/Hour: 650 SPH % Increase: 30% APIs/Hour: 23,000 Project Versions: 38,000	IOPS: Read: 25,000 / Write: 25,000 Black Duck SCA Services: CPU: 13 core / Memory: 77 GB PostgreSQL: CPU: 16 core / Memory: 64 GB Total: CPU: 29 core / Memory: 141 GB	Black Duck SCA Services: CPU: 23 → 13 core (24% improvement) Memory: 133 → 77 GB (28% improvement)
1000sph	Scans/Hour: 1400 SPH % Increase: 40% APIs/Hour: 40,000 Project Versions: 42,000	IOPS: Read: 25,000 / Write: 25,000 Black Duck SCA Services: CPU: 25 core / Memory: 172 GB PostgreSQL: CPU: 22 core / Memory: 88 GB Total: CPU: 47 core / Memory: 260 GB	Black Duck SCA Services: CPU: 46 → 25 core (29% improvement) Memory: 367 → 172 GB (43% improvement)
1500sph	Scans/Hour: 1600 SPH % Increase: 6% APIs/Hour: 50,000 Project Versions: 47,500	IOPS: Read: 25,000 / Write: 25,000 Black Duck SCA Services: CPU: 30 core / Memory: 212 GB PostgreSQL: CPU: 26 core / Memory: 104 GB Total: CPU: 56 core / Memory: 316 GB	Black Duck SCA Services: CPU: 57 → 30 core (28% improvement) Memory: 459 → 212 GB (44% improvement)
2000sph	Scans/Hour: 2300 SPH % Increase: 15% APIs/Hour: 60,000 Project Versions: 50,000	IOPS: Read: 30,000 / Write: 30,000 Black Duck SCA Services: CPU: 34 core / Memory: 254 GB PostgreSQL: CPU: 32 core / Memory: 128 GB Total: CPU: 66 core / Memory: 382 GB	Black Duck SCA Services: CPU: 64 → 34 core (30% improvement) Memory: 565 → 254 GB (45% improvement)

Note: Installing Black Duck Alert requires 1 GB of additional memory.

PostgreSQL container scaling

Customers using the PostgreSQL container will need to set the values manually using ALTER SYSTEM, and changes to shared_buffers won't take effect until after the next time that PostgreSQL is restarted.

These settings apply to both Kubernetes and Swarm installations.

Table 2. PostgreSQL Settings
Name	Details
120sph	Scans/Hour: 120 PostgreSQL CPU/Memory: CPU: 4 core / Memory: 16 GB `shared_buffers` (MB): 5336 `effective_cache_size` (MB): 6404	`autovacuum_max_workers`: 4 `maintenance_work_mem` (MB): 512 `max_connections`: 400 `work_mem` (MB): 50
250sph	Scans/Hour: 300 PostgreSQL CPU/Memory: CPU: 6 core / Memory: 24 GB `shared_buffers` (MB): 8016 `effective_cache_size` (MB): 9619	`autovacuum_max_workers`: 6 `maintenance_work_mem` (MB): 1024 `max_connections`: 500 `work_mem` (MB): 35
500sph	Scans/Hour: 650 PostgreSQL CPU/Memory: CPU: 16 core / Memory: 64 GB `shared_buffers` (MB): 21439 `effective_cache_size` (MB): 25727	`autovacuum_max_workers`: 6 `maintenance_work_mem` (MB): 1024 `max_connections`: 500 `work_mem` (MB): 35
1000sph	Scans/Hour: 1400 PostgreSQL CPU/Memory: CPU: 22 core / Memory: 88 GB `shared_buffers` (MB): 29502 `effective_cache_size` (MB): 35403	`autovacuum_max_workers`: 6 `maintenance_work_mem` (MB): 2048 `max_connections`: 600 `work_mem` (MB): 48
1500sph	Scans/Hour: 1600 PostgreSQL CPU/Memory: 26 core / Memory: 104 GB `shared_buffers` (MB): 34878 `effective_cache_size` (MB): 41854	`autovacuum_max_workers`: 8 `maintenance_work_mem` (MB): 4096 `max_connections`: 800 `work_mem` (MB): 58
2000sph	Scans/Hour: 2300 PostgreSQL CPU/Memory: 32 core / Memory: 128 GB `shared_buffers` (MB): 42974 `effective_cache_size` (MB): 51569	`autovacuum_max_workers`: 8 `maintenance_work_mem` (MB): 4096 `max_connections`: 800 `work_mem` (MB): 58

Note: The amount of required disk space is dependent on the number of projects being managed, so individual requirements can vary. Consider that each project requires approximately 200 MB.

BDBA scaling

BDBA scaling is done by adjusting the number of binaryscanner replicas and by adding PostgreSQL resources based on the expected number of binary scans per hour that will be performed. For every 15 binary scans per hour, add the following:

One binaryscanner replica
One CPU for PostgreSQL
4GB memory to PostgreSQL

If your anticipated scan rate is not a multiple of 15, round up. For example, 24 binary scans per hour would require the following:

Two binaryscanner replicas
Two additional CPUs for PostgreSQL
8GB additional memory for PostgreSQL

Important: This guidance is valid when binary scans are 20% or less of the total scan volume (by count of scans). The performance testing metrics should be used as guideline for scaling the server. Not all binaries that are of a certain size are the same in that the number of layers of extraction and the number of identified components found within the binary can require more or less resources than what was determined in the performance tests.

Black Duck recommends monitoring disk utilization on Black Duck SCA servers to prevent disks from reaching capacity which could cause issues with Black Duck SCA.

Report generation scaling

For customers looking to scale out additional reporting generation requirements, Black Duck recommends the following increases:

To achieve 190 reports generated per hour, add the following:
- 1 additional jobrunner
- 2 additional CPUs and 8GB memory for the WebApp container
- 4 additional CPUs and 16GB for the database
To achieve 460 reports generation per hour, add the following:
- 2 additional jobrunners
- 3 additional CPUs and 12GB memory for the WebApp container
- 8 additional CPUs and 32GB for the database

The resources allocated to Jobrunner in 120sph, 250sph, and 500sph deployments must be increased as follows:

Resources	CPU	Memory	Total CPU	Total Memory
Limits	2 cores	15GB	3 cores	21GB
Requests	1 core	15GB	2 cores	21GB

Note: 25,000 reports in Black Duck SCA requires roughly 3GB of additional disk storage and scales linearly as more reports are added. We recommend administrators monitor disk space usage to ensure adequate growth capacity.