What a server is, and the types of server
A server is a computer whose job is to answer other people requests, which is why it stays on all the time; its hardware is not a different kind of thing from your computer, its duty is. What we call a website server is really several layers stacked: hardware, an operating system, a web server, and the program that builds the page.
- Lesson 7 of 12
- Beginner
- Free, no signup
What we call the server, from the site down to the metal
- The siteThe only layer a visitor sees, and the only one you wrote yourself.
- The application and its runtimeRuns the site code and builds the page. Here, PHP.
- The database and the memory cacheThey hold the content and the settings. Here, MariaDB and Redis.
- The web serverTakes the request, and finishes it itself if the file is ready. Here, nginx.
- The operating system and the hardwareThe foundation. On this machine it does not even have a graphical desktop.
This layering is a learning order, not a standard. On shared hosting the bottom three layers are not reachable by you at all.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
How is a server different from the computer at your home?
In kind, almost nothing. A server has a processor, memory and a disk, and runs the same familiar instructions. The difference is the role: your computer waits for you and a server waits for the rest of the world. You close your laptop at night; a server that gets closed is no longer a server.
Every other difference follows from that one difference in role, and none of them is magic. A server usually has no screen and no keyboard because nobody sits at it. Its power and its network are doubled because going dark costs money. Its hardware reaches for parts that run for months without a pause rather than parts that are quicker in a game. And the copy of the operating system installed on it carries nothing extra; on this server the operating system does not even have a graphical desktop, and everything is done with commands.
A common mistake ends here: a server is not a particular box, it is a role. An old laptop in the corner of a room is a server too if it stays on and answers requests. What makes the price worth paying is not the box but the continuity: power, network, cooling, and somebody who answers at three in the morning.
When a request arrives, who exactly answers it?
This is where the word server splits into several separate things, and until you see that split no server problem is diagnosable. First the web server takes the request; on this machine nginx version 1.29.4 does that job. If what was asked for is a ready file, it finishes there and no other program is started. If not, it hands the request to the language runtime, here PHP version 8.5.2, which runs the site code and on the way asks the database and the memory cache.
The difference between those two paths can be measured, and the figure is startling. The front page of this site, when answered from a ready file, takes 23 milliseconds at best for its first byte to arrive. The same page, forced to be built again, takes 139 milliseconds at best. All those extra 116 milliseconds belong to the application and database layer, on the same machine, the same network and the same page. Whether a page is built in advance or built on every visit is the single largest speed decision in a WordPress site.
Two more layers sit on the same path and are seen less often. The database, here MariaDB version 10.11.10, which holds the content and the settings. And a memory cache in RAM, here Redis, which keeps the answers to repeated queries so the database does not read from disk again.
A detail almost no tutorial mentions: the web server and the language runtime on this machine do not talk over the network. Their conversation goes through a socket file on the disk itself, and the database is configured on localhost. So none of those conversations ever becomes a packet on a network. Once you know this, you stop blaming the network for a slow page.
The path of one request, and where it can end early
-
1
The request arrives
The web server takes it. No program has been started yet.
-
2
Is the file ready? Done
The web server answers by itself. On this site, 23 milliseconds to the first byte.
-
3
If not, the application runs
The runtime starts and executes the site code from the beginning.
-
4
It asks the database
And the memory cache, so the same question is not read from disk twice.
-
5
The response is built and sent
On this site 139 milliseconds, which is 116 more than the short path.
The two numbers here are the minimum of five measurements on this server and depend on the machine and on the page itself; the ratio is repeatable, the numbers are not.
How do shared, virtual, dedicated and cloud servers differ?
In one sentence: each step up gives you more control and puts exactly that much more responsibility on your shoulders. It is the second half that gets lost in the advertising.
On a shared server, dozens of sites sit on one machine and somebody else maintains the layers underneath. You have only files and a database. It is cheap and it is enough for most small sites, and its flaw is that a noisy neighbour affects you and the setting you want may not be reachable at all. On a virtual server one physical machine is divided into several independent machines and your share is guaranteed; in return the operating system is yours, and so is keeping it updated. A dedicated server is the whole box, with all of its power and all of its responsibility. And cloud is a delivery model more than a kind of hardware: you take resources by the hour and give them back, which is built for a load that rises and falls suddenly.
Our position after years of hosting client sites: almost nobody ever needs a virtual server for its power. The real reason for a move is usually one of two things: a setting became necessary that shared hosting does not have, or the neighbours got noisy enough that the site behaviour became unpredictable. If neither of those has happened, more money usually does not buy more speed.
And the boundary of that advice, stated plainly: the cost of a virtual server is not only its monthly rent, it is the time of the person who keeps it updated. If that person does not exist, an unattended virtual server is more dangerous than shared hosting, because keeping it patched is now nobody job. Choosing and buying hosting is not the subject of this lesson and is opened up in the guide to choosing a host and the article on shared hosting.
Each rung gives as much responsibility as it gives control
-
1
Shared
You have only files and a database. Every layer underneath is somebody else work, and a noisy neighbour is somebody else problem until it reaches you.
-
2
Virtual
Your share is guaranteed and the settings are in your hands. In return the operating system, and keeping it updated, is yours from today.
-
3
Dedicated
The whole box is yours and nobody else is on it. Its cost is also the whole box, whether you use it or not.
-
4
Cloud
More a delivery model than a kind of hardware: you take resources by the hour and give them back. Built for a load that rises and falls suddenly, not for a site with steady traffic.
This ladder is not a growth path and climbing it is not a goal. Most sites work correctly on the first rung, and climbing without a reason only adds maintenance work.
Why does a server fall over?
The common assumption is that the processor fills up. In practice it almost never is that. What runs out is concurrency: the number of workers allowed to run the site code at any one moment.
On this very server that number is configured and it is twenty. So at any instant at most twenty requests can enter the application layer, and the twenty first has to wait. Now suppose each of those twenty takes three seconds instead of a hundred milliseconds, because a heavy query or an outside service got slow. Your capacity drops suddenly from two hundred requests a second to about seven, without the processor even getting warm. The queue grows, waiting time climbs, and from the outside this looks exactly like the server going down.
There is a second ceiling that few people know about, and it is written in the same place: each request has at most 180 seconds and is then cut off without mercy. That is good protection, because one broken request cannot hold a worker forever. But it also means long jobs such as taking a backup or importing a large file get cut right in the middle, and without a clear error message. If a job always fails at around three minutes, do not go looking for a bug; you have hit the ceiling.
The practical consequence of those two numbers is one simple rule: making pages faster does not only improve the user experience, it multiplies the capacity of the server, because every worker is freed sooner. That is why caching a page, whose difference you saw in the previous section, is a capacity decision more than a speed optimisation.
What is not the server job?
This section exists to stop the most common way money is wasted in this area. A stronger server does not make a heavy page light. If a page loads three megabytes of images and calls twenty external scripts, doubling the server processor changes almost nothing, because the bottleneck is not there at all. The server is only responsible for sending the first byte quickly; the rest of the work happens in the visitor browser.
Three other things are not the server job either and are regularly blamed on it. The security of the site code: a fully patched server can still run a vulnerable plugin. The quality of the database: a bad query on better hardware is only slightly faster at being bad. And backups: no server takes a backup of itself on its own, and that is a sentence usually understood when it is already too late.
So the right order of work is this: first find where the slowness is, then spend money. If the bottleneck is building the page, caching and the database are the answer; if the bottleneck is something happening in the browser, no server will help you and the work continues in the site speed track.
The fast path, with AI
The ordinary way to find out whether the server or the site is slow is to guess and then change hosts. The fast way is to take two simple measurements that already contain the answer, and let the language model do nothing but read them for you. The whole thing takes two minutes and its result is that you know which layer ate the time, rather than what might be to blame.
- Take the time to first byte for the normal page five times and keep the minimum: curl -s -o /dev/null -w "%{time_starttransfer}\n" https://example.com/. We keep the minimum because one network wobble ruins an average.
- Repeat it with a meaningless parameter such as ?x=1234 so the page cache is bypassed and the application is forced to actually build the page. Now you have two numbers, and their difference is exactly the cost of the application layer.
- Take the headers of both as well (curl -sI), because they say which layer answered. Then hand all four pieces over with the recipe below. A fast, cheap model is enough; the current pick in each class is kept in our AI reference.
- Before buying anything, weigh the answer against the section on what is not the server job. If the difference between the two numbers was small, the bottleneck is not on the server at all and changing hosts is money thrown away.
Copy-ready recipe
You are a web infrastructure specialist. Judge only from the data below and add nothing from memory.
Address: {page address}
A) Time to first byte, normal page, minimum of five: {number} seconds
B) Time to first byte, same page with a meaningless parameter, minimum of five: {number} seconds
Headers for A:
{paste here}
Headers for B:
{paste here}
Write four things:
1. What B minus A is, and which layer that difference belongs to.
2. Whether A was answered from a page cache. Quote the header that shows it. If there is no such header, write "cannot tell".
3. Given these two numbers, whether the bottleneck is in building the page. One sentence, with the reason.
4. If the bottleneck is in building the page, two actions in order of effect that can be done on this same server and need no change of host.
Rules: never write a header that is not in the text. Do not invent a number. If the data is not enough for one of the points, write which further measurement is needed.Before you trust the output: Three things must never be pasted: the site configuration file, which holds the database password; the web server configuration, which gives away internal paths and addresses; and a raw log, which usually contains the addresses and sessions of real users. None of them are needed for this job; two numbers and two sets of headers are enough, and that narrow input is half the value of the method.
AI in this kind of work
On this topic a language model has made something cheap that used to be expensive: reading. An unfamiliar piece of configuration or a log line whose meaning you do not know is explained in seconds, and that single step removes the distance between not knowing what is going on and knowing what to look for. But the moment the work means touching the server, a model memory is no substitute for the documentation of the exact version you installed.
Tools that actually help
- Claude Good at reading the raw output of commands and explaining a configuration line by line, and those two jobs carry the most value in this lesson. Iran is not on Anthropic list of supported countries, so there is no official route to sign up or pay.
- Gemini Notebook This is the real trick of this lesson: upload the official documentation of the exact version you installed and ask the question inside that document. The answer comes from the vendor text, so the name of a setting is no longer a guess. It runs on a Google account, and Iran is not among the available regions.
Where it backfires
Two risks, and both happen in this exact topic. First, what you paste. The configuration file of a WordPress site contains its database password, and a web server configuration is a full map of the internal paths; these look harmless for diagnosis and they are not. Google says plainly on its own page about Gemini data that you should not enter confidential information, which means the vendor treats this as a real boundary too. Second, a setting that does not exist. The model states the path of a command or the name of a configuration option with complete confidence, and that option is not in the version you installed or means something else; Anthropic itself calls this confident invention hallucination in its documentation and writes about reducing it. On a live server the cost of that mistake is different from the cost of a wrong answer in a chat, because the site goes down. Our position is simple: ask the model for the concept, the documentation of that exact version for the precise name of a setting, and never run a command you do not understand on a live server.
Sources: Google: Gemini Apps privacy and data Anthropic: reduce hallucinations Anthropic: supported countries Google: where Gemini Apps are available
Where this advice stops
This lesson builds the concept and does not make you a server administrator. Installing and hardening a server, the firewall, updates and monitoring are each their own job and are not here. Choosing and buying hosting is deliberately left out too, and is opened up in the guide to choosing a host. And let us state the boundary of the numbers plainly: every figure here comes from the configuration and measurement of this one machine. The worker count, the time ceiling and the versions differ on any other server, and comparing them directly with yours is not sound; what transfers is the method, not the figure.
From our own work
Everything in this lesson comes from the configuration and measurement of the server that just handed you this page, on 7 September 2026. The layers are these: nginx version 1.29.4 as the web server, PHP version 8.5.2 as the runtime, MariaDB version 10.11.10 as the database and Redis as the memory cache. The web server and the runtime talk to each other through a socket file on the disk itself rather than over the network, and the database setting is localhost. The concurrency ceiling of the application layer is twenty workers and the time ceiling of one request is 180 seconds; both are written in the configuration and are not a guess. And the speed measurement: the front page of this site takes 23 milliseconds at best from a ready file, and the same page forced to be built takes 139 milliseconds at best to the first byte, each the minimum of five runs and taken straight from the server itself so that the content delivery network plays no part in the result.
Real follow-up questions
How many simultaneous visitors can my server take?
That number does not come from the processor, it comes from a simple division: the number of workers divided by how long each request takes. With twenty workers and a hundred milliseconds per request, about two hundred requests a second; with the same twenty workers and two seconds per request, ten. That is why shortening each request is more effective than buying a bigger server.
Why did my site not get faster on the new host?
Because the bottleneck was probably not on the server. The server only decides the time to the first byte; if the slowness comes from the weight of images and scripts that run in the browser, the best server in the world does not change it. The test is the same two measurements from the fast path section: if the difference between the cached and uncached page is small, the money went to the wrong place.
What is the difference between a server and hosting?
A server is the machine and hosting is the service you buy on it. When you buy hosting you are renting a share of a server together with its maintenance and support, not the machine itself. That is why "I bought hosting but I have no access to the server settings" is not a contradiction; it is exactly what you bought.