What we do · Storage and compute
Performance and capacity engineering
Most slow platforms do not need more hardware. They need someone to find the one thing actually holding them back. We measure the real bottleneck, change one thing, and measure again, and most of our biggest wins have come from a single verified change rather than a purchase order.
What it is
The engineering practice that ties our compute, storage and network together. When a workload needs more capacity, we tell you exactly which resource, and why.
How we build it
Rules applied to every build. Some wins are too reliable to leave to chance, so they are standing rules on every server and VM we deliver:
- VMs sized inside one socket. Never more vCPU than one physical socket has cores, never more memory than one NUMA node serves. Past that boundary, memory access goes remote at roughly 1.7 times local latency and the penalty compounds, so the bigger VM is often the slower one.
- Bonds that use both links. Hashing on IP addresses and ports, matched on the switch side, so every member of a bond carries traffic.
- Flash treated as flash. Hardware RAID can hide the fact that a volume is solid state, so we read the media type from the drives and set the scheduler, read ahead and queue depth to match.
- Databases given their memory. Buffer pools sized to the working set.
- No swap on VMs. Memory pressure is solved with memory or with a fix in the application, never by pushing it onto storage.
Measurement at every layer. Per-volume I/O on the arrays, per-port counters on bonds and switches, query and slow logs on databases, outside-in timing through the CDN, power per rack and per phase.
What it protects you from
- Paying for capacity a configuration default was wasting.
- Buying hardware for a problem that is really a tuning problem.
- A bigger VM that runs slower than the smaller one it replaced.
- Half of your network bandwidth sitting idle.
- Flash storage spending its endurance on reads a database should have cached.
In practice
A publisher's edge, proven under load. Before launch in Athens, the publisher's caching tier was built as two layers, memory in front of flash on the SAN, and load tested at twenty thousand virtual users. It held, and the design became our standard for publisher platforms.
Why EuroVPS
- We measure before we sell, and the answer is often a change, not an upgrade.
- Standing tuning rules applied to every build, not on request.
- Recommendations that say which resource, how much and why.
FAQ
My site is slow. Do I need a bigger server? Maybe, but we will measure first. Often the answer is configuration, caching or a query, and we will show you the evidence either way.
Why will you not give my VM more cores? Past one socket, extra cores add remote memory latency. We size to fit the socket, and that is usually faster.
Do you tune customer applications? We tune everything we run and advise on what you run: database memory, worker counts, caching layers, queries. Where the fix is in your code, we will tell you exactly where.
Is this a separate service? It is how we work on every platform we manage. Dedicated performance audits with a written before and after are also available.
Faster usually starts with a measurement, not an invoice. Talk to an engineer about what is really slowing you down.
Your next infrastructure partner
Let’s look at
your setup.
Tell us what you run today and what needs to improve. An engineer will review your brief and help you plan the next step.
+357 222 32280
who will look after your infrastructure.
Let’s start with your setup.
A little context helps us start the right conversation.