This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Deliver a mission-critical, production grade architecture and infrastructure
Right-Size Deployment Instances to Meet Enterprise Demand
- From monitoring systems - From business marketing stats - Current data - Future / Projected data
Gather Data : Types
- Expected maximum throughput/TPS - Expected latency - Size of messages - Work done per transaction
Expected Maximum TPS / Peak load
- You have to know TPS or TPM (per minute). Transactions per day is useless unless we have some store and process model in the architecture. Often, most messages in a day come within minutes.
- When there is no numbers to refer try to get a rough idea, is it 10s, 100s 1000s or 10000s?
- Remember, this is Maximum value, not the average
Size of Messages
- Try to classify them to following - Small (<50k) - Moderate (<1M) - Large (<5M) - Extra large (> 5M)
- If messages greater than 1M, better to a trial run as results are very unreliable
Transaction : Identify the CPU cycles
Apply to each deployment architecture layer
Component Capacity Planning Guidelines
API Gateway Peak load of the API calls
Auth Server Peak load of the API calls
API Store Peak load of the subscriptions and browsing
API Publisher Peak load of the API publishing and LCM tasks
Analytics System load of the API calls
Example : API Manager Capacity Planning
Refer available performance numbers
Compute the instances Pattern With WSO2 Analytics With WSO2 LB
But … try it on your environment with the use-cases
- Performance test - Actual use-cases - Message sizes - Infrastructure - Tools (Jmeter/SOAP-UI/Grinder ….)
Work with a WSO2 Consultant
- Fill the capacity planning sizing parameter doc - Work with a WSO2 consultant
Things to consider
- Keep a buffer of 30% - Should not load servers beyond 25% of normal instantaneous peak load - Allocate 2GB memory per Carbon instance/ JVM - Keep minimum 2GB memory for the OS and system utilities - Use system load (TPD/TPY) for data / log growth - Keep performance test (2x) and long running test as part of the
acceptance test
Extend the deployment
- Secure vault - Headless worker nodes - Connect to the existing user-store (LDAP/AD/RDBMS) - Fine-tune , thread pools, throttling - Command-line tools - Connect to SDLC, change control
Summary
- Identify the deployment patterns - Consider the deployment needs and constraints - Draw the deployment architecture (logical)
- Identify the architecture layers
- Gather data - Current - Future
- Refer performance statistics for a given HW and use-case(s) - Compute the instance count per each layer - Identify the physical architecture