What dedicated server hosting do I need for a high-traffic website?

How do I size a server for a high-traffic website?

Start from peak requests per second and how long each request holds a worker, not from visitors per month. Multiply the two and you get the number of workers busy at any instant. At 300 requests per second and 0.1 seconds each, 30 workers are busy on average. Double that for spikes.

Monthly visitors do not size a server; the busiest minute does.

• CPU. A request that computes uses one core while it runs. CPU-bound workers need roughly one core each. Workers that wait on a database or an API can outnumber cores.
• Memory. Each worker holds its own memory. Multiply the per-worker figure by the worker count, then add the database cache and the operating system.
• Storage. Busy sites are often limited by their database. Local NVMe keeps queries and logs off slow disks.

Lumenfer publishes no benchmarks, so measure your own application. Load-test a copy with a tool such as k6 or wrk, and read peak memory per worker from top.

How many workers should PHP-FPM, Node.js and nginx run?

Set PHP-FPM's pm.max_children from memory, run one Node.js process per core, and let nginx start one worker per core.

• PHP-FPM. The PHP manual says pm.max_children limits how many requests are served at once. static keeps that many children running; dynamic and ondemand start them as needed. pm.max_requests respawns children after a set count, a fix for leaky libraries.
• Node.js. One Node.js process runs JavaScript on one thread. The cluster module runs several processes that share a port. Its documentation example forks one worker per availableParallelism().
• nginx. The nginx manual calls one worker process per CPU core a good start, and auto detects the count. worker_connections defaults to 512 and counts upstream connections too. The open-files limit caps it, so raise worker_rlimit_nofile alongside.

# /etc/nginx/nginx.conf
worker_processes auto;        # one per CPU core
worker_rlimit_nofile 65535;   # open files per worker
events {
    worker_connections 8192;  # clients and upstreams together
}

# PHP-FPM pool, e.g. /etc/php/<version>/fpm/pool.d/www.conf
# pm = static
# pm.max_children = 64        ; free RAM for PHP / peak memory per child
# pm.max_requests = 1000      ; respawn children to contain leaks

How much bandwidth does a high-traffic website use?

Less than you fear once a CDN serves the static files, more than you expect without one. The HTTP Archive's Web Almanac 2025 puts the median home page at 2.86 MB on desktop and 2.56 MB on mobile. The figures come from its July 2025 crawl. Images and JavaScript make up the largest share.

The arithmetic for an origin with no CDN:

• 1 TB of traffic carries about 390,000 uncached mobile home-page loads at 2.56 MB.
• A 1 Gbit/s port tops out at 125 MB each second: roughly 49 of those pages per second.
• Thirty days flat out add up to roughly 324 TB.

At the median page weight, a single 1 Gbit/s origin tops out near 49 uncached page loads a second. A CDN changes that: the origin then sends mostly HTML and API responses. Lumenfer plans range from 30 TB a month at 1 Gbit/s to 150 TB a month at 1 Gbit/s. Going over never triggers an automatic charge.

Do I need a CDN in front of a dedicated server?

Yes, for any site that expects real traffic: it offloads static bytes, absorbs spikes and stands between attackers and your origin. DDoS protection is limited to whatever the datacenter network applies by default; nothing further is promised. A flood sent to the server's single IPv4 address lands on your machine directly.

Publish only the CDN's addresses in DNS and let the origin accept web traffic from the CDN alone. No logs are kept: no connection logs, no traffic logs and no visitor or customer IP addresses, on the site, in the dashboard or on the servers. A CDN you add keeps its own logs under its own policy, so read it before you choose one.

Which CPU suits a busy website: high clock or many cores?

High per-core speed for response time, more cores for requests in parallel. A single PHP or Node.js request mostly runs on one core, so that core's speed sets its latency. The core count sets how many requests run at the same moment.

The Ryzen plans pair fewer cores with desktop-class clock speeds. The EPYC plans add cores and ECC memory. Our guide to the best CPU for a rented server compares them, and the fastest server you can rent explains which criteria decide speed.

Should the database run on the same server as the website?

On one machine, yes, until the database and the workers start competing for RAM. Shared hardware keeps queries local and costs one plan. When the database cache gets squeezed, move the database to its own server with ECC memory, and connect the two over TLS.

Our page on the best server hosting for PostgreSQL covers memory, storage and backups for that second machine.

When is one server not enough for a high-traffic website?

When an hour of downtime costs more than a second server. One machine is one point of failure. There is no IPMI or KVM-over-IP console for customers: you request reboots and reinstalls in the dashboard and the team performs them. Backups are not included: keep copies of your data somewhere else.

For availability, run a second server in another city with database replication, and fail over through DNS or your CDN. Amsterdam (Netherlands), Reykjavik (Iceland), Zurich (Switzerland) and Bucharest (Romania): all five plans in all four cities, one price everywhere. A standby in Zurich or Reykjavik costs exactly what it costs in Amsterdam.

In Lumenfer's check of 30 October 2026, 27 of 34 dedicated-server sellers priced their entry server on a pre-2018 processor. Every Lumenfer plan runs a 2022-or-newer CPU, DDR5 and NVMe. Compare the full cost against cloud hosting in is bare metal cheaper than the cloud, and see every plan on the Lumenfer pricing page.