2.5 Performance Objectives
Official task mapping
SAP-C02 task 2.5: Compute, storage and database knowledge; bottleneck-driven service selection. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review EC2, ElastiCache and DynamoDB. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Measure before selecting
Translate requirements into throughput, tail latency, concurrency and data correctness. Profile CPU, memory, I/O, network and database waits independently. Choose instance families and EBS performance according to the bottleneck; an instance’s storage/network limits can cap a faster volume.
Cluster placement favors low-latency communication within an AZ; spread/partition placement isolates failures with scope-specific quotas. The seven-instance spread constraint concerns rack-level spread per AZ, not a universal limit on partition placement or every spread mode. Confirm current supported modes before designing a large fleet.
ElastiCache supports Valkey, Redis OSS and Memcached with distinct deployment/serverless options. Cache choice includes eviction, consistency, failure and cost concerns. DAX requires a compatible client/endpoint integration; it is not an invisible no-code DynamoDB switch. Strongly consistent requests bypass its cache.
Read replicas can improve read scale but introduce replication-lag and consistency decisions. CloudFront caches eligible content; Global Accelerator improves supported network routing and does not cache responses.
Compute and caching reference
| Family characteristic | Typical workload | Verify before choosing |
|---|---|---|
| Compute optimized | Batch/media/HPC | CPU efficiency, network and architecture |
| Memory optimized | Large working sets/in-memory processing | Peak memory and licensed core cost |
| Storage optimized | Local high-I/O datasets | Persistence/recovery and instance-store loss |
| Accelerated | Supported training/inference/rendering | Framework, accelerator and driver support |
| General purpose | Balanced application work | Actual bottleneck, not family familiarity |
Cluster groups favor nearby supported instances; spread separates supported hardware failure boundaries; partition groups isolate sets used by distributed stores. Group choice does not replace replication or application failure handling.
Valkey/Redis OSS options provide supported richer data structures/replication capabilities; Memcached deployment modes have different simplicity, sharding and availability behavior. Do not apply one old node-based Memcached claim to every current serverless mode. CloudFront Origin Shield can reduce duplicate origin work but adds its own feature charges and configuration concerns.
For 10,000 requests/second, a 60% hit rate leaves 4,000 origin requests/second; 95% leaves 500. Confirm cacheable fraction, invalidation and cold-cache behavior before claiming the backend can be downsized eightfold. Cache failure can suddenly restore 10,000 requests/second. Read replicas/DAX also require application routing, consistency and failover validation.
Scenario and rationale
A catalog API needs p99 below 100 ms, tolerates 30 seconds of stale product descriptions, but inventory counts must be current. Cache descriptions with bounded TTL/invalidation while keeping stock updates/reads on a consistency-appropriate database path. Measure cache hit ratio and backend saturation.
Reject caching all responses identically: stale stock can oversell. Reject a larger EC2 instance if tracing shows database lock contention. Reject a DAX retrofit without application/client and consistency validation.
Practice drill
Given p50/p99 timings for network, application and database stages, identify the dominant tail-latency source. Estimate origin load at 60% and 95% cache-hit ratios for 10,000 requests/second. Propose a representative benchmark with latency, correctness and cost acceptance criteria and a cache-failure fallback.
References
- Official Domain 2 task guide
- EC2 placement groups
- ElastiCache overview
- DAX consistency and integration
Return to Domain 2. The drill is proposed study work, not a claim of a completed deployment.
Across the wiki
- Chaos Engineering — performance and chaos testing (Kubernetes)
- Performance Testing — performance and chaos testing (Architecture)
- Network Performance Tuning — performance and chaos testing (Linux)
- Performance Tuning — performance and chaos testing (Kubernetes)