Sizing Tips for AX 2009

Dynamics AX Performance Team

 Core Sizing Considerations and
Influences
Data
Customizations
Composition

User
Characterization Reporting Usage
(Type, Patterns
Concurrency)

Hardware 3rd Party

Transaction
Characterization Sizing Solutions (Non
Specifications AX)
 Sizing: Guidance on Transactions Vs
User Count
• Size by Transaction Volume (Specifically Line
Volume)
• Number of Concurrent Users is a required
tenet but is secondary to transactions.
• Consider the Parameters/Data Composition
under which transactions are being executed
• Consider Reporting Volumes and Report Types
(Transactional/Trends/Detailed Listing etc)
• Define Multiple Peak Periods, if different
 Sizing: Guidance on Concurrency
• Named Users ARE NOT Concurrent Users
• Concurrent Users are always Subset of Named
Users
• Peak Workload defines Maximum Concurrency
for Sizing
• CRITERIA for Concurrent User:
– Logged On AND
– Working Transactions/Inquiries at the time of
Counting AND
– Not an IDLE SESSION
 Database Server Sizing Tips
4K to 12K Lines Per Hour Per Core on Data base Server
Major Swing is based on:
Parameter Settings being used
Level of Customization
Usage of additional functionality like databaselog and alerts etc
2 GB to 4 GB Memory for Each Core
Use the Benchmark reports for Comparative Sizing

Benchmark Lines Per Hour Per Memory Per

Core Core
Day in the Life Benchmark ~10,000 Lines 4 GB
Enterprise Portal benchmark ~7500 Lines 4 GB
AIF Benchmark(Batch) ~50000 Lines 2 GB
Time Entry Benchmark (In Draft) ~9500 Lines 2 GB
 AOS Server Sizing Tips
Server Size: 2 to 8 Processor Box (2 Proc Quad Core, 2 Proc Dual, 4 Proc
Dual, Single Proc Quad)
Multiple Instances Can run on same box – Use Processor Affinity
Memory Per Instance : 2 to 4 GB of Physical Memory
Network: GIG NIC Cards and a GIG Network.
How to Size:
Use Transaction Counts and indicators from Benchmarks/Internal
testing
User Concurrency is a good Marker. Based on Transaction Complexity,
between 25 Users Per Core to 150 Users Per Core

Benchmark Lines Per Hour Per Users Per Core

Core
Day in the Life Benchmark ~8,000 Lines 55
Enterprise Portal benchmark ~7500 Lines 125
AIF Benchmark(Batch) ~25000 Lines Batch Only
Time Entry Benchmark (In Draft) ~9500 Lines 300
 Terminal Server Sizing Tips
Client Memory Considerations Drive Sizing
What else are you running on the Server?
Office etc
What Controls are you running on the Client?
Browser Controls
Custom Controls
Base Client Sizing Guidelines
50 MB to 140 MB per Client Instance. Usage determines Peak memory footprint per
Client. Use Client Configuration settings to manage memory.
Additional Controls will have additional footprint
2 Core Box 4 GB memory is a base Server. Multiples of this Server and/or a Server Farm
can help Scale.
Latency Guidance
AX 2009 is Terminal Server Free if running:
ON LAN
OR WAN with SSRS Reporting and on Base Transactions upto 50 ms Latency. Custom Transactions need
optimization for RoundTrips before use without Terminal Server.
AX 2009 Requires Terminal Server if running:
On WAN AND
Uses X++ reporting
Enterprise Portal Server Sizing Tips
Server Size: 2 to 8 Processor Box (2 Proc Quad Core, 2 Proc Dual, 4 Proc
Dual, Single Proc Quad)
2 to 4 GB Per Core
This guidance is x64 only
Network: GIG NIC Cards and a GIG Network.
How to Size:
Use Transaction Counts and indicators from Benchmarks/Internal
testing
User Concurrency is a good Marker. Based on Transaction Complexity,
between 50 Users Per Core to 150 Users Per Core
Benchmark Lines Per Hour Per Users Per Core
Core
Day in the Life Benchmark ~2000 Lines 20 (Box not fully
utilized)
Enterprise Portal benchmark ~3200 Lines 60
Time Entry Benchmark (In Draft) ~2700 Lines 80
Dynamics AX 2009: Batch Server Sizing
Transaction Throughput needs consideration
Transaction Complexity and Locking Model
Rules of Thumb
2 Threads per Core for Dedicated Batch Servers
Heavy Duty transactions that are long running should be 1 Thread Per Core
Batches Are Assigned to Batch Groups
Batch Servers Participate in Batch Groups
Batch Threads are allocated on Batch Servers
Make Sure your Batch Group Allocation does not cause Resource conflicts for other batch jobs.