4.3 Performance Efficiency
Recommended
AWS Performance
Azure Performance
GCP Performance
Recommended
Recommended
Comprehensive
Comprehensive
Purpose
Section titled “Purpose”Performance Efficiency focuses on using computing resources efficiently to meet requirements and maintaining that efficiency as demand changes and technologies evolve. Evaluate this quality attribute across all architectural views documented in Section 3.
4.3.1 Performance Requirements
Section titled “4.3.1 Performance Requirements”Key Performance Indicators
Section titled “Key Performance Indicators”| Metric | Target | Measurement Method |
|---|---|---|
| Response time (P50 / P95 / P99) | [e.g., < 200ms / < 500ms / < 1s] | [how measured] |
| Throughput | [e.g., 1000 requests/sec] | [how measured] |
| Concurrent users | [e.g., 10,000 simultaneous] | [how measured] |
| Batch processing time | [e.g., < 2 hours for daily batch] | [how measured] |
| Data processing latency | [e.g., < 5 seconds end-to-end] | [how measured] |
Guidance
Set targets based on real user expectations, not arbitrary numbers. Consider:
- P95/P99 response times — these matter more than averages; a 200ms average with a 5s P99 is a poor experience
- Throughput — derive from expected user volumes and usage patterns, not theoretical maximums
- Batch processing — define the acceptable window (e.g., must complete before business hours)
- Measurement method — specify whether targets are measured at the client, load balancer, or application layer
Performance Testing
Section titled “Performance Testing”| Attribute | Detail |
|---|---|
| Performance testing approach | [load testing, stress testing, soak testing] |
| Testing tools | [e.g., JMeter, Gatling, k6, Locust] |
| Testing environment | [which environment, how it compares to production] |
| Testing frequency | [when performance tests are run] |
Capacity & Growth Projections
Section titled “Capacity & Growth Projections”| Metric | Current | 1 Year | 3 Years | 5 Years |
|---|---|---|---|---|
| Users (total) | [n] | [n] | [n] | [n] |
| Concurrent users (peak) | [n] | [n] | [n] | [n] |
| Data volume | [n GB/TB] | [n GB/TB] | [n GB/TB] | [n GB/TB] |
| Transaction volume (per day) | [n] | [n] | [n] | [n] |
| Storage requirement | [n GB/TB] | [n GB/TB] | [n GB/TB] | [n GB/TB] |
| Question | Response |
|---|---|
| Will the current design scale to accommodate projected growth? | Yes / No — [if no, describe what changes will be needed] |
| Are there known seasonal or cyclical demand patterns? | Yes / No — [if yes, describe peak periods] |
4.3.2 Resource Optimisation
Section titled “4.3.2 Resource Optimisation”Document how the solution optimises resource usage:
| Strategy | Implementation |
|---|---|
| Right-sizing | [how compute resources are sized appropriately] |
| Caching | [caching layers and strategies] |
| Connection pooling | [database and service connection management] |
| Asynchronous processing | [use of queues, background jobs] |
| Content delivery | [CDN usage for static assets] |
| Database optimisation | [indexing strategy, query optimisation] |
4.3.3 Network Performance
Section titled “4.3.3 Network Performance”Cross-reference Section 3.3.3 for network topology. This section documents performance-specific network considerations:
| Attribute | Detail |
|---|---|
| Latency requirements | [round-trip time expectations] |
| Bandwidth requirements | [data transfer volumes] |
| QoS requirements | [quality of service needs] |
| Content delivery strategy | [CDN, edge caching, regional deployment] |
| Network optimisation | [compression, connection reuse, protocol choice] |
Scoring Guidance
| Score | What This Looks Like |
|---|---|
| 1 | General performance expectations stated but no targets |
| 3 | Response time, throughput, and concurrency targets defined; growth projections documented |
| 5 | All of the above plus performance testing automated, caching strategy documented, resource optimisation evidenced, seasonal patterns accounted for |