Understand the infrastructure behind your workload.

Start with what your application does and who will operate it. Understand the control you need, identify compute, memory, storage and network constraints, then check protection and recovery before planning growth.

1. Describe the workload and its users.
2. Choose the required control and isolation model.
3. Estimate compute, memory, storage and network needs.
4. Assign administration and maintenance responsibilities.
5. Check security and recovery requirements.
6. Use those requirements to compare suitable infrastructure.

A hosting model describes both a resource boundary and a responsibility boundary. Shared web hosting usually gives you an account within a provider-operated server environment. You manage your site through account-level tools while the provider operates the underlying operating system and hosting stack. Account isolation and resource policies help separate customers, but an account is not the same thing as a guest operating system.

A virtual private server provides a guest environment on a physical host. A dedicated server assigns a physical machine to one customer. Those models offer different degrees of operating-system control, customization and isolation. Neither label alone tells you who will patch your application, monitor its database or restore a damaged installation.

Storage, streaming and GPU infrastructure describe workload priorities. They are not steps on a ladder that every application must climb, and they do not automatically include a particular software bundle. Start with permissions and dependencies as well as capacity: an application can need more control long before it needs more processing power.

KVM uses the Linux kernel’s virtualization capabilities to run virtual machines. A hypervisor presents virtual hardware to each guest: processors, memory, disks and network interfaces. The guest runs its own operating system and applications, while the host schedules work on the underlying hardware. Guest isolation does not, by itself, specify how physical processing time is allocated.

A vCPU is a processor presented to a virtual machine. It is not automatically a dedicated physical CPU core. Scheduling, contention and any guaranteed allocation depend on the service. KVM can support overcommitment, so the virtualization technology alone is not evidence of a no-overselling policy.

Root on Linux and Administrator on Windows are privileged roles inside the environment you control. They do not necessarily provide access to the host, network equipment or every hardware function. A shared-hosting control panel instead exposes a narrower set of account and service operations. Choose the permission boundary your software needs, then establish who is responsible for using that access safely.

A physical processor contains cores. A core executes instructions, while hardware threads can expose additional execution contexts on a core. A vCPU is a virtual execution resource, not a universal unit of physical performance. Counts, clock speeds and model names each describe only part of a processor’s behavior; architecture, generation and the application’s instruction mix also matter.

Serial work follows a critical path that cannot simply be divided among more workers. Parallel work can use multiple execution resources, but coordination, shared data and contention can limit the benefit. A slow database query, compression job and video transcode can therefore respond very differently to the same increase in core count. Measure representative work instead of treating more cores as an automatic latency improvement.

RAM holds the system’s working data: application processes, database caches, filesystem cache and guest memory where virtualization is used. An undersized working set can force expensive data movement, but unused memory does not compensate for every CPU or storage limit. Look at busy-period behavior and the application’s actual memory demand before increasing capacity.

GPU compute addresses particular forms of parallel work and adds another memory domain: VRAM. The GPU chapter explains why system RAM and GPU-local memory need separate planning. A balanced workload plan considers the entire path rather than selecting the largest specification in every column.

HDD describes rotating magnetic media. SSD describes solid-state media. SATA and NVMe describe interfaces or protocols, so “SSD versus NVMe” mixes categories: an SSD can use NVMe. For a local storage decision, compare the actual drive type and interface together, such as a SATA HDD, SATA SSD or NVMe SSD.

Capacity tells you how much data fits. Latency describes how long an operation takes; IOPS counts operations per second; throughput measures data moved per unit of time. Small random requests and large sequential transfers stress storage differently. Read/write mix, request size, queue depth and the rest of the system influence the result, so an interface label does not establish an application benchmark.

Keeping the operating system on a separate system drive can simplify how a large data pool is organized and maintained. It does not make either location a backup. Plan usable space after the selected layout, metadata and reserves, and consider growth, temporary files and recovery work as well as the initial dataset.

Redundancy and recovery solve different problems. A mirror may continue operating after a particular drive fails, while a recovery copy can help recover an earlier state after deletion or corruption. A design must identify the failures it addresses rather than relying on the word “protected.”

RAID 0 stripes data without redundancy. RAID 1 mirrors data. Conventional two-copy RAID 10 combines mirrored sets with striping; whether multiple failures are survivable depends on which members fail and the implementation. Usable capacity and failure tolerance must both be considered. RAID does not undo a deletion that is written to every member.

A snapshot records a point-in-time state, but it may depend on the same storage system. A backup needs a usable recovery copy and a way to restore it; a snapshot is not automatically an independent backup. Local, remote and offsite copies cross different failure boundaries. Access separation and retained versions matter when the problem is compromise rather than hardware failure.

Define how much recent data could be lost and how long recovery can take, then test the restore process. Check application consistency, retention, credentials and encryption keys. An untested copy may exist without providing the recovery outcome you expect. Product inclusions and operator responsibilities must be agreed separately.

A port or uplink rate is a connection capacity, usually stated in bits per second. Traffic or transfer is an accumulated quantity over time, usually stated in bytes. Throughput is the rate actually achieved across a particular path. “Bandwidth” is often used for either capacity or transfer in commercial language; read the unit and the service terms to distinguish them.

Unmetered traffic does not mean unlimited speed. The port, remote network, congestion, server, application and service policy can still constrain throughput. Dedicated, shared and guaranteed describe different commitments and need the actual service wording. A rate label is not a promise that every remote endpoint can sustain that rate.

Eight bits make one byte: 1 Gbps converts to 125 decimal MB/s before protocol overhead and other limits. Decimal GB and binary GiB use different multipliers. Keep these units visible when estimating transfers, and do not equate an ideal conversion with measured application payload.

Latency includes path delay, while a user-visible response also includes DNS, connection establishment and application work. Ping observes ICMP behavior; traceroute and MTR provide route-probe observations. An intermediate silent hop alone does not establish forwarding loss. Compare endpoint results over time. A controlled iperf test needs permitted cooperating endpoints and describes that test path, not every application or destination.

Protection capacity describes the scope or scale of a mitigation service. A service uplink describes the connection serving your infrastructure. They are separate properties: a large mitigation capacity does not turn the server connection into a link of the same size. Bits per second, packets per second and requests per second also describe different workloads and cannot be ranked as interchangeable numbers.

Network and upstream mitigation act on traffic before it reaches or overwhelms a protected path. A web reverse proxy receives web requests on the proxy path and can apply application-facing controls. Other proxy models exist, so “reverse proxy” should not be read as a universal statement about one protocol layer or architecture.

Origin exposure, routing and configuration matter. A local application rate limit can reduce expensive request processing, but it cannot recover capacity on an upstream connection that is already saturated. Application bottlenecks can also occur with traffic that does not look like a simple high-volume network flood.

DDoS mitigation reduces risk; it does not guarantee zero downtime. Understand which traffic is covered, what reaches the origin and which responsibilities remain with you. Keep access control, patching and recovery planning alongside traffic protection. No single protection metric describes the availability of the entire application.

A media delivery plan starts with bitrate and concurrent sessions, then follows the work back to its origin. Multiplying concurrent sessions by an average delivered bitrate gives a payload estimate. Variable bitrate peaks, multiple renditions, protocol overhead and retransmissions make the real demand more complex. Do not treat the arithmetic as a universal viewer limit.

Origin capacity also depends on storage access, application behavior and cacheability. An optional edge or CDN layer can change how much traffic reaches the origin, but its role depends on the architecture and content. Do not assume that a CDN is included with a server or that every live or personalized response can be cached.

Pass-through or streamcopy moves media without decoding and re-encoding it. Transcoding decodes media and produces a new encoded output, potentially with processing between those stages. Codec, quality settings, resolution and the number of renditions affect compute demand. Supported CPU or GPU acceleration depends on the software and workload.

Plan delivery and processing separately, then inspect their shared constraints: disk reads, temporary files, CPU, memory and network. A connection upgrade does not solve a saturated encoder. Measure busy periods and failure scenarios before choosing extra capacity; there is no single headroom percentage suitable for every stream.

A GPU performs particular parallel computations, using GPU-local memory commonly called VRAM. System RAM and VRAM serve different parts of the workload. Unified addressing or memory features do not make their placement, access cost or physical capacity identical. Check where the application actually keeps its data and what must move between devices.

Two GPUs with 24 GB each do not automatically provide one universally usable 48 GB allocation. Software may run independent jobs, replicate a workload or explicitly partition it across devices. Per-device data residency, supported communication paths and the application’s parallelization strategy determine what is practical.

Training and inference have different resource patterns. Model state, intermediate data, precision, batching and context all affect memory demand. Rendering and other compute workloads introduce their own requirements. A GPU label alone is not a prediction of useful throughput, and a software stack must support the required hardware features.

CPU preprocessing, system RAM, storage and checkpoint movement can become bottlenecks even when GPU capacity appears sufficient. Test representative data and software before choosing an accelerator configuration. Plan how data enters the system, how results leave it and how failed or interrupted work is recovered.

An operating system provides the underlying execution environment. A control panel such as cPanel or DirectAdmin is a software layer for managing services; it is not the operating system. Check application dependencies and supported environments without assuming that an old version list describes current deployment options.

Managed and unmanaged are responsibility boundaries to agree, not universal bundles of tasks. Assign OS patching, application updates, access controls, monitoring, escalation and backups explicitly. Administrative access gives you the ability to make changes; it does not establish that someone else will maintain or recover those changes.

Find the critical bottleneck before scaling. CPU, RAM, storage I/O, network, GPU memory, database contention and application architecture can all limit a workload. Measure representative busy periods and investigate the slowest stage. Buying the maximum of every resource can leave the actual problem unchanged.

Vertical scaling adds resources to a node. Horizontal scaling adds nodes and requires the application to coordinate work and state across them. Sessions, databases, background jobs and recovery behavior can affect whether that is straightforward. Plan headroom around demand peaks and failure cases rather than applying a fixed percentage to every system.