How to Accurately Estimate Server, Storage, and Performance Resources for Enterprise Systems

1 Terminology and Definitions

1.1 Information System A human‑machine system composed of computers, communication devices, processing devices, control devices and related facilities that, according to specific purposes and rules, collects, processes, stores, transmits and retrieves information.

1.2 Software‑Hardware Platform The environment in which an information system runs, mainly including hardware (servers, storage) and software (operating system, database, middleware).

1.3 Non‑Secure Zone The Internet, a region that allows external users unrestricted access.

1.4 Secure Zone The internal network, typically not providing services to the outside.

1.5 DMZ (Demilitarized Zone) An area between the non‑secure zone and the secure zone that, as needed, provides certain services to external users.

1.6 FC SAN (Fiber Channel Storage Area Network) A storage‑area network that uses fiber‑channel technology to integrate storage devices, connection devices and servers into a high‑speed network, isolated from LANs and primarily responsible for data storage.

1.7 FC Switch (Fibre Channel Switch) A high‑speed network relay device that uses fiber as the transmission medium and forms part of an FC SAN.

1.8 HBA (Host Bus Adapter) A circuit board or integrated circuit that provides I/O processing and physical connection between a computer and storage devices.

1.9 RAID (Redundant Arrays of Inexpensive Disks) A group of multiple small, slower disks combined to improve overall performance and capacity.

1.10 Virtual Machine A logical computer system with complete hardware functions that runs in an isolated environment using system virtualization technology.

1.11 Load Balancing Includes hardware and software load balancing; software load balancing installs balancing software on one or more servers, while hardware load balancing places dedicated devices between servers and external networks.

1.12 Critical Application Systems Applications that are core to business operations and have very high requirements for reliability, availability and serviceability, such as asset management, marketing, finance, HR, collaboration and integrated management systems.

1.13 Non‑Critical Application Systems Applications other than critical ones.

1.14 TPC‑C Test Simulates a wholesale order‑management system to evaluate database transaction processing performance (OLTP). The result is expressed as tpmC (transactions per minute).

1.15 SPECweb2005 Measures web‑server performance by sending HTTP GET requests from many clients; the higher the number of answered requests, the better the web performance.

1.16 Business Transaction In TPC‑C estimation, each user request (query, modify, delete) counts as one business transaction.

1.17 Hierarchical Storage Stores data on different storage tiers (disk, disk array, optical library, tape library) and automatically migrates data between tiers via management software.

2 Basic Principles

Architecture Consistency Principle.

Security Principle.

Reliability Principle.

Scalability Principle.

Green Low‑Carbon Principle.

3 Software‑Hardware Platform Architecture

From a security perspective, networks are divided into DMZ and secure zones. Systems should be placed according to security‑level protection requirements, following partitioning, grading and domain principles.

For simple maintenance‑free applications, a Browser/Server (B/S) architecture is recommended; for performance‑critical or complex UI applications, a Client/Server (C/S) architecture is suggested.

Low‑performance B/S applications may use a three‑tier web‑client / application‑server / database‑server model; high‑performance B/S applications should adopt a four‑tier model (adding a dedicated web server for HTTP handling).

4 Storage Devices

Storage includes local server/VM storage and shared storage. Structured data should use FC SAN or high‑bandwidth InfiniBand‑based disk arrays; unstructured data can use cost‑effective NAS.

Storage switches should be redundant (2N) and support trunking for multi‑storage sharing.

Storage should support virtualization, open interfaces, dynamic scalability without service interruption.

Both DMZ and secure zones should each configure a set of shared storage devices.

Critical applications should use hierarchical storage, placing frequently accessed data on fast disks/arrays and less‑frequent data on slower, cheaper media such as tape libraries.

5 Database Servers

For critical Oracle clusters, use multiple small servers with virtual partitioning; distribute nodes of the same application across different physical partitions.

Oracle RAC is recommended to leverage load balancing and real‑time disaster recovery.

Guidelines:

Avoid storing identical tables on multiple RAC nodes; keep data localized to reduce inter‑node communication.

Configure services with priority ordering (e.g., three servers A, B, C with three service definitions ABC, BCA, CAB).

Consider master‑slave replication, vertical or horizontal partitioning for high‑load scenarios.

Master‑slave replication: write on master, replicate during low‑traffic periods.

Vertical partitioning: separate data types onto different nodes.

Horizontal partitioning: distribute rows of a table across nodes.

6 Application/Web Servers

Use micro‑servers or blade servers; virtualize to host multiple application/web servers on a single physical host, balancing nodes across physical servers for high availability.

Low‑resource systems without special hardware can run on VMs to improve utilization.

VM data should reside on shared storage.

Critical applications should place hardware load balancers in front of application/web clusters.

When clustering WebLogic, avoid shared file or time services; ensure static IPs, same LAN, same software version, and consistent JDBC and servlet configurations.

Do not place the admin server of WebLogic inside the cluster.

Web servers can use caching to improve performance.

7 Load Balancing

Load‑balancing devices are mainly used for application and web servers; critical systems should share hardware load balancers.

Two deployment modes: direct and bypass; bypass mode with multiple devices connected to core switches provides redundancy.

WebLogic recommends 25‑50 threads per CPU core; exceed this by adding servers and using load balancing.

8 Resource Allocation Methods

Estimate storage resources using decomposition, database servers with TPC‑C, web servers with SPECweb2005, and application servers with SPECjbb2005.

Basic steps:

If a single server can meet capacity, do not split into multiple physical servers.

For dual‑node Oracle RAC, increase capacity by 50% for redundancy.

For application clusters ≤4 nodes, assume 60% of total node capacity; >4 nodes, assume 50%.

For web clusters ≤4 nodes, assume 70% of total node capacity; >4 nodes, assume 60%.

The guide mainly covers storage, database, application and web server resource estimation; other server types can be estimated similarly.

9 Server Resource Estimation Methods

9.1.1 Method 1: Database Server TPC‑C Estimation

Applicable to estimating CPU capacity for database (and optionally application/web) servers. Compute TPC‑C value using the formula: TPC‑C = ((TASK × 80%) / T) × S × F / C Where:

TASK : Total business transactions on a typical workday.

T : Duration (minutes) of the peak transaction period.

S : Complexity factor relative to standard TPC‑C.

F : Future growth reserve factor.

C : Target CPU utilization (commonly 75%).

Steps include estimating total daily transactions, peak duration, peak per‑minute transactions, transaction complexity, future reserve, then applying the formula.

9.1.2 Method 2: Unpublished Server TPC‑C Estimation

When a server model’s TPC‑C is not published, estimate it from a fully‑configured model assuming linear relation between TPC‑C, CPU count and frequency:

Estimated TPC‑C ≈ (Published TPC‑C ÷ Published CPU‑count ÷ Published CPU‑freq) × Target CPU‑count × Target CPU‑freq

9.1.3 Method 3: Web Server SPECweb2005 Estimation

Applicable for estimating web‑server capacity to meet throughput and response‑time requirements.

SPECweb2005 = (Total Users × Online Rate × Avg HTTP Requests per Online User) / (1 – Redundancy Rate)

9.1.4 Method 4: Application Server SPECjbb2005 Estimation

Evaluates Java‑application server performance. SPECjbb2005 = A × B / (1 – C – D) Where A is peak transactions per second, B is Java‑ops per transaction, C is redundancy reserve, D is non‑Java resource usage.

9.1.5 Method 5: Database Server Memory Estimation

Two approaches:

4 GB memory per CPU core (e.g., 2 × 4‑core CPU → 32 GB).

Calculate total memory needed for OS, database software, cache (≈5 % of frequently accessed data), and concurrent connections, then divide by platform‑specific utilization limits (55 % for Windows, 60 % or 80 % for Unix/Linux depending on total size).

10 Storage Resource Estimation

Estimate storage for databases, ordinary files, and system operation.

Database storage = Σ (Entity Record Count × Record Size) + Σ (Index Size) plus redundancy.

File storage = Sum of log, transaction, and billing files, plus redundancy.

System storage = OS, application software, and other tools, plus redundancy.

Apply capacity redundancy (e.g., 30 %) and RAID redundancy (e.g., RAID10 adds 100 %).

Examples illustrate calculations for TPC‑C, SPECweb2005, and storage sizing with concrete numbers.