Rackoona and the infrastructure behind your hosting: what to check

Behind most hosting services sits a stack of other companies: data centres, hardware, networks and sometimes whole server platforms supplied by an infrastructure provider such as Rackoona. For you as a customer, the partner's name matters less than four practical questions: what resources your plan actually gets, where your data lives, what the service level really promises, and who you call when something breaks. This guide explains how the layers fit together, what Rackoona says about its own services, and how to test any host's performance yourself with a few safe commands.

The layers behind a website

Think of hosting like a restaurant chain. The building might be leased, the ovens bought from a supplier, the ingredients delivered by a wholesaler, and the staff trained by the chain. The customer still expects one thing: a good meal, and someone to talk to if it is not.

Hosting has similar layers:

• The facility: the data centre building, power, cooling and physical security.
• The hardware: servers, storage drives and memory.
• The network: connections between servers and out to the internet.
• Virtualisation: the software that splits a physical server into VPS slices or shared hosting accounts.
• The operating system and control panel: Linux, cPanel or DirectAdmin, web and mail servers.
• Your application: WordPress, a shop or your own code.

One company rarely owns every layer. What matters is that someone takes clear responsibility for each one, and that you know who your point of contact is when a problem crosses layers.

What Rackoona says about itself

Rackoona's website describes "High-performance USA VPS and RDP hosting" and dedicated servers, aimed at uses such as forex trading, gaming and web development. At the time of writing (3 October 2026), it lists data centres in Salt Lake City, Chicago and Delhi, and makes these hardware claims:

• Processors: "AMD EPYC 7003 (Milan) and 9004 (Genoa) series processors with up to 3.7GHz boost clocks".
• Storage: "Samsung PM9A3 enterprise NVMe SSDs".
• Network: "10Gbps fiber uplinks".
• Memory: "ECC DDR4/DDR5 registered memory".

It states a 99.9% uptime SLA. Those are Rackoona's own statements about its own products. They are useful context, but they do not automatically describe any other company's plan, including a plan that uses some of that infrastructure. Always confirm the details of the exact service you are buying with the company you buy it from.

Specifications versus what your plan gets

Fast hardware is a good foundation. It is not a promise about your account. Two plans on identical servers can feel completely different depending on how resources are shared.

Ask about:

• CPU and memory allocations: dedicated cores, or a share of a busy server?
• Disk I/O limits: NVMe drives are fast, but your account may be capped well below what the drive can do.
• Network: is a "10 Gbps" figure the server's uplink, shared by many customers, or your own port speed?
• Overselling policy: how many accounts or VPS slices share one machine?
• Location: which data centre your service actually runs in, and whether you can choose.

A plan's limits often matter more for performance than the brand of processor in the rack.

Test performance yourself

You do not need to trust anyone's numbers. A few safe commands give you real measurements from where your visitors are.

Time a page load with curl

This breaks one request into stages: DNS lookup, connection, TLS handshake, time to first byte and total time:

curl -o /dev/null -s -w "dns: %{time_namelookup}s  connect: %{time_connect}s  tls: %{time_appconnect}s  first byte: %{time_starttransfer}s  total: %{time_total}s\n" https://example.com/

Run it several times, at different times of day. A slow first byte usually points to the server or the application (uncached WordPress pages, heavy plugins). A slow connect time often reflects distance or network routes, which is why data centre location matters.

Check the route and latency

From your own computer, mtr (available for Linux and macOS) shows each hop to the server and where delay or packet loss appears:

mtr -rw example.com

On Windows, tracert example.com gives a simpler view.

Measure the pages that matter, beyond the homepage

Run your key pages through PageSpeed Insights, and compare the server response time with and without caching. Our LiteSpeed Cache guide shows how much caching changes the picture on WordPress.

If you test load, do it gently and only on your own site

A small load test can show how a site behaves with several visitors at once. Use a tool such as ApacheBench (ab) with very modest numbers, only against a site you own, and tell your host first, because heavy testing can look exactly like an attack:

ab -n 100 -c 5 https://example.com/

That sends 100 requests, five at a time. Watch for errors and how response times change, not for a single headline number.

On a VPS, check what you were given

Once logged in, these show the processor, memory and disk you actually have:

lscpu
free -h
df -h

Read the SLA properly

An uptime percentage sounds precise. Read what sits around it.

• What it allows: 99.9% uptime still permits about 43 minutes of downtime in a 30-day month.
• Promise or aim: some terms say a provider "guarantees" a figure; others say it will "strive" to meet it. Those are different commitments.
• What is excluded: scheduled maintenance, events outside the provider's control, problems caused by your own code or configuration, and sometimes email delivery.
• What you get if it is missed: a service credit, a refund, or nothing specified. Find out how to claim and by when.
• How it is measured: by whose monitoring, from where, and over what period.

As an example of reading carefully: Hostlelo, which publishes this blog, says in its Terms of Service that "We strive to maintain 99.9% uptime for all hosting services," and lists exclusions including scheduled maintenance, force majeure, client-side application issues, suspensions for policy violations, problems from your own configuration, and email deliverability and SMTP port availability. Read any provider's terms with the same attention.

Who supports what

When something breaks, the worst answer is "that's the other company's problem". Before you buy, ask:

• Who is my single point of contact for support?
• Which layers does that contact handle: hardware, network, operating system, control panel, application?
• On an unmanaged VPS, what is my responsibility? Usually the operating system, firewall, updates and everything above them.
• How are incidents communicated, and is there a public status page?
• How fast does an urgent ticket get a human response?

Hardware redundancy protects against some failures, such as a dead drive. It does not restore a hacked WordPress site or a deleted database. That is what backups and a restore process are for, so ask about those separately.

Where does your data live?

• Primary data: which data centre, in which country, holds your site and database.
• Backups: where copies are stored, and whether they are in a different facility from the live server.
• Logs and support access: where logs are kept and who can access them.
• Moving regions: whether you can move your service to another location later, and how.

If you have legal or contractual requirements about where data is stored, such as customer contracts or local rules, get the answers in writing. Our India DPDP Rules checklist covers one example of why data handling questions matter for small businesses.

Signs a hosting service is well run

You cannot inspect a data centre yourself, but you can look for evidence that a provider takes the basics seriously:

• A public status page with a history of incidents and honest write-ups, rather than a permanent green light.
• Clear documentation of resource limits, backup schedules and retention.
• Named locations for each product, rather than vague "global network" claims.
• Specific answers from support to specific questions, including the uncomfortable ones about limits and exclusions.
• Written terms that match the sales page, especially on uptime, backups and renewal prices. Our guide to reading hosting renewal prices shows how to check the money side.

None of these proves a service is perfect. Together they show a provider that expects to be asked and is prepared to answer.

A made-up example of why this matters

Rohan runs a booking site for a tour company in Jaipur. He picks a VPS advertised with "enterprise NVMe and 10 Gbps networking", but does not ask where it is located. His server sits in the United States, and most of his customers are in India. The hardware is excellent; the first byte from Jaipur is still slow, because every request crosses an ocean. A five-minute question about location, and a quick curl test from his own city, would have pointed him to a nearer data centre.

The one message worth forwarding

Send this to any host you are considering:

"For the exact plan we are looking at, can you confirm the CPU, memory and disk I/O allocations, the data centre location, where backups are stored, what the uptime commitment says about exclusions and credits, and who our single point of contact is for support across hardware, network and software?"

The takeaway: infrastructure partners and hardware specifications are a good start, but your plan's limits, location, SLA wording, backups and support ownership decide what you actually get, so ask, test and get answers in writing.