Choosing a business server is not simply a matter of buying the model with the highest specifications.
An oversized server increases purchase and operating costs, while an undersized system can create slow applications, limited storage and expensive upgrades soon after deployment.
The right configuration depends on the applications being hosted, the number of users, expected growth, availability requirements and the way the server will be managed.
A structured sizing process helps the business purchase enough capacity without paying for resources it is unlikely to use.
Start With the Workload
Server sizing should begin with the workload rather than the hardware catalogue.
Identify what the server will run, such as:
- File sharing
- Business applications
- Databases
- Email services
- Virtual machines
- Backup software
- Website hosting
- Remote desktop sessions
- Accounting or ERP systems
- Development and testing environments
Different applications use server resources in different ways.
A database may need fast storage and substantial memory, while a file server may depend more heavily on storage capacity and network performance. A virtualisation server usually requires a balanced combination of CPU, memory and storage.
Ask the software vendor for minimum and recommended requirements, but do not rely on those figures alone. Minimum specifications often describe what is required to start the application, not what is needed for acceptable performance under real business usage.
Estimate the Number of Users
The number of users affects server demand, but total user count does not always show the complete requirement.
Consider:
- How many users have accounts
- How many users are active at the same time
- Which applications they use
- How much data each user creates
- Whether usage is consistent or concentrated during busy periods
- Whether remote users will connect through the server
A system with 100 registered users may have only 20 active at once. Another system with 30 users may experience heavy simultaneous database activity.
Concurrent usage is usually more important than the total number of accounts.
Where possible, measure current utilisation during normal and peak business periods before replacing an existing server.
How to Size the CPU
The processor determines how quickly the server can complete calculations and application tasks.
CPU sizing involves more than counting cores. Important factors include:
- Number of processor cores
- Processor generation
- Clock speed
- Cache
- Number of physical processors
- Application licensing
- Virtualisation requirements
- Power consumption
Modern processors with fewer cores may outperform older processors with a higher advertised core count.
Workloads That Need More CPU Cores
Additional cores are useful for workloads that can process many tasks at the same time, including:
- Virtualisation hosts
- Multi-user business applications
- Web hosting environments
- Analytics
- Rendering
- Software development
- Multiple database instances
A virtualisation server needs enough cores to support all virtual machines without creating excessive processor contention.
However, allocating one physical core for every virtual CPU is not always necessary. The appropriate ratio depends on workload intensity and peak usage.
Workloads That Need Higher Clock Speed
Some applications benefit more from faster individual cores than from a large number of slower cores.
These may include:
- Certain databases
- Accounting software
- Legacy applications
- Applications with limited multi-core support
- High-frequency transactional systems
Check whether the software is designed to use many cores efficiently.
Buying a processor with more cores may provide little benefit if the application primarily uses one or two processing threads.
Allow for Peak Demand
Average CPU utilisation can be misleading.
A server may operate at 20% utilisation most of the day but reach full capacity during reporting, backups, user logins or batch processing.
The configuration should handle normal peak periods without remaining close to maximum utilisation for long periods.
A reasonable target is to maintain enough spare processor capacity for growth, temporary demand and maintenance tasks.
How to Size Memory
Memory, often called RAM, allows the server to keep active data and applications readily available.
Insufficient memory can force the operating system to move data between RAM and storage. This can reduce performance significantly, even when the processor is not fully utilised.
Memory requirements depend on:
- Operating system
- Number of applications
- Number of users
- Database size
- Virtual machines
- File-system caching
- Future expansion
Include the Operating System
The operating system requires its own memory before any business application is started.
Security software, monitoring agents, backup tools and management utilities also consume RAM.
Do not allocate all installed memory to the primary application.
Include Every Application
Estimate memory requirements for every service that will run on the server.
For example, a server may need capacity for:
- Operating system
- Database
- Business application
- Backup software
- Security tools
- Monitoring
- File caching
If the server will run multiple virtual machines, calculate the memory required by each virtual machine and add capacity for the virtualisation platform itself.
Databases Often Benefit From More Memory
Databases can use memory to cache frequently accessed information.
More RAM can reduce the need to read data repeatedly from storage, improving response times.
The most suitable amount depends on database size, activity and application design. Large databases do not always need to fit entirely in memory, but frequently used data should be accessible without constant disk activity.
Plan Memory Modules Carefully
The total amount of RAM is not the only consideration.
Review:
- Number of available memory slots
- Supported module sizes
- Processor memory channels
- Maximum server capacity
- Required memory speed
- Error-correcting memory support
A server filled with small memory modules may be expensive to upgrade because existing modules must be removed.
Using fewer, higher-capacity modules can preserve expansion options, although the configuration should still follow the manufacturer’s recommended memory population rules.
How to Size Storage Capacity
Storage sizing should be based on usable capacity rather than the total advertised capacity of the installed drives.
Usable capacity is affected by:
- RAID configuration
- File-system overhead
- Operating system
- Applications
- Databases
- Backups
- Snapshots
- Recovery partitions
- Future growth
A server with several terabytes of raw storage may provide substantially less usable space after resilience and system requirements are included.
Calculate Current Data Requirements
Begin by identifying how much data the business currently stores.
Include:
- Shared files
- Databases
- User profiles
- Application files
- Email data
- System files
- Virtual-machine disks
- Local backups
- Archived data
Review data growth over the previous 12 to 24 months where records are available.
Avoid estimating future storage from the current total alone. A business that currently stores 2 TB but adds 1 TB each year will require a very different configuration from one whose data volume is stable.
Allow for Future Growth
A server should not be deployed with storage already close to full.
Insufficient free space can affect:
- Application performance
- Database operation
- Backup jobs
- Software updates
- Log files
- Virtual machines
- Recovery procedures
Estimate growth over the intended server lifecycle, which may be three to five years.
Also consider planned changes such as:
- More employees
- New applications
- Higher-resolution media
- Longer data-retention periods
- Additional virtual machines
- Increased backup history
Expansion bays can provide flexibility, but future drive availability and compatibility should be confirmed.
Choose the Right Storage Type
Capacity alone does not determine storage performance.
The main choices generally include hard disk drives and solid-state drives.
Hard Disk Drives
Hard disk drives can provide high capacity at a lower cost.
They may be suitable for:
- File archives
- Large shared folders
- Backup repositories
- Infrequently accessed data
- Workloads where capacity matters more than speed
Solid-State Drives
Solid-state drives provide faster access and lower latency.
They are often better suited to:
- Databases
- Virtual machines
- Business applications
- High-activity file systems
- Systems with many simultaneous users
Some servers use a combination of both. Fast storage can support active applications, while higher-capacity drives store archives or backup data.
Consider Storage Performance
Storage performance can become a bottleneck even when sufficient capacity is available.
Important factors include:
- Read and write activity
- Number of simultaneous operations
- Drive type
- RAID level
- Storage controller
- Cache
- Interface speed
- Application latency requirements
A database server may need relatively little storage capacity but very high transaction performance.
A backup server may need much more capacity but can often operate with lower-performance drives.
Sizing should therefore consider both capacity and workload behaviour.
Select an Appropriate RAID Configuration
RAID combines multiple drives to improve resilience, performance or both.
Common options include:
RAID 1
RAID 1 mirrors data across two drives.
It provides simple resilience but reduces usable capacity by approximately half.
It is often used for operating-system drives or smaller servers.
RAID 5
RAID 5 uses distributed parity and can tolerate one drive failure.
It provides better usable capacity than mirroring but may have slower write performance and longer rebuild times on large drives.
RAID 6
RAID 6 can tolerate two drive failures.
It offers stronger protection for larger arrays but requires additional capacity for parity.
RAID 10
RAID 10 combines mirroring and striping.
It can provide strong performance and resilience but uses approximately half of the installed raw capacity.
The appropriate RAID level depends on performance requirements, drive size, recovery risk and budget.
RAID is not a backup. It improves availability after a drive failure but does not protect against deletion, corruption, ransomware or complete server loss.
Include Backup Requirements
Backups should be planned separately from the server’s main storage.
The business should decide:
- Which data must be backed up
- How frequently backups run
- How long copies are retained
- Whether backups remain on-site
- Whether off-site or cloud copies are required
- How quickly data must be restored
- How much backup storage is needed
Backup capacity can exceed the amount of live data, particularly when the business keeps several versions or long retention periods.
Avoid using the same storage array as both the primary system and the only backup location.
Size Virtualisation Hosts Carefully
A server hosting virtual machines must support the combined requirements of all guest systems.
For each virtual machine, estimate:
- Virtual processors
- Memory
- Storage capacity
- Storage performance
- Network usage
- Expected peak activity
Then add capacity for:
- Hypervisor
- Management tools
- Backup operations
- Snapshots
- Future virtual machines
- Failover requirements
Do not simply add every virtual machine’s maximum allocation without considering actual usage. However, avoid excessive overcommitment unless utilisation is being monitored closely.
Memory is often the first resource to become constrained in virtualisation environments.
Consider Redundancy and Availability
A correctly sized server can still become a single point of failure.
Depending on the importance of the workload, consider:
- Redundant power supplies
- RAID-protected storage
- Spare drives
- Multiple network interfaces
- Backup power
- Secondary servers
- Replication
- Clustering
- Disaster recovery
If the business cannot tolerate extended downtime, sizing one powerful server may be less effective than deploying two smaller systems with failover capability.
Capacity planning should include what happens when a component or server is unavailable.
Avoid Sizing Based Only on Minimum Requirements
Minimum vendor specifications are useful as a starting point, but they may not account for:
- Peak activity
- Data growth
- Additional applications
- Security software
- Backups
- Reporting
- Future users
- Operating-system updates
Recommended specifications are usually more useful, but they should still be checked against the organisation’s actual workload.
Where possible, request sizing guidance from the application vendor or an infrastructure supplier familiar with the software.
Avoid Oversizing Without a Reason
Buying the largest available server may appear safe, but it can create unnecessary costs.
Oversized systems may result in:
- Higher purchase price
- Increased software licensing
- Greater power consumption
- More expensive support
- Unused expansion capacity
- Higher replacement costs
Some software is licensed by processor core, physical processor or virtual machine. Additional hardware can therefore increase recurring costs even when the resources remain unused.
A better approach is to purchase enough capacity for current requirements, realistic growth and a sensible operating margin.
Use Current Performance Data
When replacing an existing server, collect performance information before selecting the new configuration.
Monitor:
- Average and peak CPU utilisation
- Memory usage
- Storage capacity
- Storage latency
- Disk activity
- Network traffic
- Application response times
- User concurrency
Measurements should cover normal business periods and known peak events.
This information is more reliable than estimating requirements from employee count or server age alone.
A Practical Sizing Checklist
Before requesting a server quotation, confirm:
- Which applications will run on the server?
- How many users will access them?
- How many users will be active simultaneously?
- What are the application vendor’s requirements?
- How much CPU is currently used at peak times?
- How much memory is currently used?
- How much data is stored today?
- How quickly is data growing?
- What level of storage performance is required?
- Which RAID configuration is appropriate?
- How much backup capacity is needed?
- Will the server host virtual machines?
- What growth is expected over three to five years?
- How much downtime can the business tolerate?
- Which components must be redundant?
- How will the server be upgraded later?
These answers give suppliers the information needed to recommend a suitable configuration.
Final Recommendation
Size the CPU according to application behaviour, concurrent activity and peak processing demand.
Size memory for the operating system, applications, active users, databases and virtual machines, while preserving room for future expansion.
Size storage using usable capacity rather than raw drive capacity, and include RAID overhead, backups, snapshots and expected data growth.
The best server is not necessarily the one with the highest specifications. It is the system that provides sufficient performance, resilience and expansion capacity for the expected workload at a sustainable total cost.
Ila Express supplies business servers configured around application requirements, user demand, storage growth, virtualisation and availability needs.
Contact Ila Express to review your workload and prepare a correctly sized server configuration.
