Architecture Overview
Understanding the application architecture is the foundational step in performance testing. Visualizing how data moves through different layers of the infrastructure helps determine where queues form, resource boundaries exist, and where transactional latency is introduced.
Why We Model Architecture for Testing
Determine if latencies originate in the web server, app code runtime, database query execution, or third-party APIs.
Identify system sizing limits (CPU, memory, storage) and simulate load requirements for future scalability.
Highlight external API integrations and authentication providers to configure appropriate mocks and timeouts.
Analyze clustered configurations to plan stress tests that evaluate database replica switchovers and load balancer rules.
Technology Stack Summary
| Layer | Component Name | Technology Stack | Version | Primary Responsibility |
|---|---|---|---|---|
| Client / Load Balancer | Virtual Users / ALB | F5 BIG-IP / AWS ALB | - | Traffic distribution, TLS termination, and reverse proxying |
| Web Layer | Web Application Server | Microsoft IIS | 10.0 | Static asset caching, HTTP compression, and thread request queueing |
| Application Layer | Application Logic Engine | .NET Core Runtime | 6.0 | Processing business rules, user sessions, and database connections |
| Data Cache | Distributed Cache | Redis Cache | 6.2 | In-memory database query result caching and fast session storage |
| Database Layer | Relational Database | Microsoft SQL Server | 2019 | ACID compliant storage, transactional query indexing, and lock management |
Logs, Reports, Uploads
ASP.NET Cache
Windows Event Logs
Component Configuration
| Component | Host Name | IP Address | OS | CPU | RAM | Role |
|---|---|---|---|---|---|---|
| Application Server | app-server-01.qa.local | 10.10.10.10 | Windows Server 2019 | 8 vCPU | 16 GB | Web + App + Logic |
| Database Server | db-server-01.qa.local | 10.10.10.20 | Windows Server 2019 | 8 vCPU | 16 GB | Database |
| File Storage | app-server-01.qa.local | 10.10.10.10 | Windows Server 2019 | - | - | Local Storage |
| Parameter | Value |
|---|---|
| Web Server | IIS 10.0 |
| Application Framework | .NET Core 6.0 |
| Application Path | C:\inetpub\wwwroot\PerfApp |
| App Pool | PerfAppPool (.NET v6.0, Integrated) |
| Max Concurrent Requests | 10000 |
| Session Mode | InProc |
| Authentication | Forms Authentication |
| Logging Enabled | Yes |
| Error Handling | Custom |
| Parameter | Value | Parameter | Value |
|---|---|---|---|
| Database Type | Microsoft SQL Server 2019 (15.0.2000.5) | Isolation Level | Read Committed |
| Database Name | PerfTestDB | Recovery Model | Full |
| Authentication | SQL Server Authentication | Auto Growth | Enabled |
| Max Connections | 200 | Initial Size | 5 GB |
| Connection Timeout | 30 sec | Max Size | 50 GB |
| Service | Endpoint | Protocol | Timeout | Purpose |
|---|---|---|---|---|
| Payment Gateway API | https://api.payment.com | HTTPS | 30 sec | Process Payments |
| Email Service | https://api.email.com | HTTPS | 20 sec | Send Notifications |
| Third Party API | https://api.thirdparty.com | HTTPS | 30 sec | External Integrations |
Clustered Hosting Configuration
| Component | Host Name | IP Address | OS | CPU | RAM | Role |
|---|---|---|---|---|---|---|
| Load Balancer | alb-prod-01.local | 10.10.20.5 | ALB Appliance OS | 4 vCPU | 8 GB | Traffic Distributor |
| Web Node 01 | web-server-01.local | 10.10.20.10 | Windows Server 2019 | 4 vCPU | 8 GB | Reverse Proxy / Static Content |
| Web Node 02 | web-server-02.local | 10.10.20.11 | Windows Server 2019 | 4 vCPU | 8 GB | Reverse Proxy / Static Content |
| App Node 01 | app-server-01.local | 10.10.20.20 | Windows Server 2019 | 8 vCPU | 16 GB | Business Logic Thread Pool 1 |
| App Node 02 | app-server-02.local | 10.10.20.21 | Windows Server 2019 | 8 vCPU | 16 GB | Business Logic Thread Pool 2 |
| DB Primary | db-master-01.local | 10.10.20.40 | Windows Server 2019 | 16 vCPU | 32 GB | Relational Writes (Transactional) |
| DB Replica | db-replica-01.local | 10.10.20.41 | Windows Server 2019 | 16 vCPU | 32 GB | Relational Reads (Reporting) |
Component Specifications
Receives front-end connections from users. Handles static resource caching, TLS/SSL session negotiations, HTTP headers validation, and reverse proxying to Kestrel logic threads.
Performance Metrics: Current Connections, Requests/sec, Thread Count, gzip compression efficiency, and Kernel URI cache hit ratio.
Runs the primary business calculations, manages connection strings to the database, parses API JSON requests, and manages transient memory variables.
Performance Metrics: Garbage Collection (GC) CPU pause time, Gen 0/1/2 collection counts, Thread pool queue count, and active database connection pool.
Caches repetitive SQL queries, catalogs, and stores user sessions. Avoids database roundtrips.
Performance Metrics: Cache Hit Ratio, Memory Fragmentation, Connections Count, Operations/sec, and command processing latency.
Saves orders, profiles, and transactional data in primary storage. Evaluates query indexing and relational table keys.
Performance Metrics: Page Life Expectancy (PLE), Buffer Cache Hit Ratio, User Connections, Active Lock Waits, TempDB usage, and physical disk Read/Write latency.
Service Dependency Map
| Dependency Node | Connection Protocol | Auth Method | SLA Timeout | Failure Severity | Failure Impact description |
|---|---|---|---|---|---|
| Database Server | ADO.NET Connection Pool (TCP 1433) | SQL Authentication | 30 seconds | Critical | Application cannot read or write data. All user transactions crash instantly. |
| Redis Cache | StackExchange.Redis Socket (TCP 6379) | Token Password | 2 seconds | Moderate | Application falls back to database queries. Response times increase by ~200ms. |
| Payment Gateway API | HTTPS REST API Calls | OAuth 2.0 Client Tokens | 30 seconds | High | Checkout flow fails. Users cannot execute payment transactions. |
| Email Dispatch API | HTTPS SOAP / REST Web Service | API Key header | 20 seconds | Low | Email receipts are queued locally. No immediate user transaction disruption. |
Transaction Data Flow (Checkout Scenario)
This step-by-step timeline represents how data propagates across layers when a user executes a "Purchase Checkout" transaction.
The user browser sends a HTTPS POST payload containing order details to the load balancer over the public internet network.
ALB decrypts/terminates SSL encryption, inspects host headers, and forwards the raw HTTP stream to the Web Server (IIS 10.0) pool.
IIS accepts the socket request, verifies static rules, and hands over execution thread to Kestrel (.NET Core Application Pool).
The application logic queries the Redis cache server to retrieve the user's session state and shopping cart variables (cache hit).
The ADO.NET connection layer pulls a socket from the pool and queries the SQL Server relational database to check inventory counts.
The application logic issues an outbound HTTPS REST call to the third-party payment gateway to authorize payment. This is the main contributor to overall response times.
Upon successful payment, the application executes a database transaction to insert orders and update inventory database records.
The application formats a JSON response object, sends it through IIS to the load balancer, which encrypts it and returns it to the client browser.
Component Interactions & Protocols
| Interaction Path | Protocol Type | Connection Rules | Performance Tuning configuration |
|---|---|---|---|
| Client to Load Balancer | HTTP/2 over TLS 1.3 | Persistent connection reuse | Keep-Alive Timeout = 60s, Max Keep-Alive requests = 1000 |
| Load Balancer to Web Server | HTTP/1.1 (TCP 80) | Reverse Proxy multiplexing | SSL decryption is handled at ALB to offload Web Server CPU |
| App Server to Database | TDS Protocol (TCP 1433) | ADO.NET connection pool | Max Pool Size = 200, Connection Timeout = 30s, Pooling = true |
| App Server to Cache | Redis Serialization Protocol (RESP) | Reused Multiplexed TCP Sockets | KeepAlive = 60s, ConnectTimeout = 2000ms, SyncTimeout = 1000ms |