Why is our hosting not just simple hosting, but much more?

Since 2005, when I founded Dreamsnet.it as a small one-man company, until its transformation in 2018 into Managed Server Srl, my professional goal has always been one: offer a better hosting service. Not “better than” someone, but THE BEST in an absolute sense.

As a Formula 1 preparer which dismantles the machine piece by piece to eliminate unnecessary weight and superfluous frills, I designed the entire software stack following a clear principle: maximize performance and performance, even at the cost of sacrificing every comfort deriving from obsolete, slow and compromised panels such as Plesk, cPanel, or DirectAdminThe truth is simple: if you want a racing car, you can't afford accessories that slow you down.

From this philosophy comes a Managed professional hosting service - Meaning what managed, followed and cared for — with higher costs than standard market offers, but with a technical support and expertise which have nothing to do with the copycat solutions offered by the usual panel resellers posing as system administrators. We don't sell "hosting" in the traditional sense. We build high-performance, robust and scalable platforms for those who demand the best.

Every now and then someone asks me:

Marco, but why should I pay? 137 euros per month plus VAT for your managed dedicated server hosting, when I find offers out there 50, 60, 70 euros per year?

And you know what I always answer?

I won't explain it to you in words. I'll tell you. a true storyThen draw your own conclusions.

The following is another story that adds to the long list of last-minute rescues. This isn't a glossy brochure. It's an account of what happens when you deal with... complex sites, delicate applications, customers who have to bill every single minute… and how, in certain cases, the difference between a “classic” hosting and ours is literally between living and dying online.

The call you don't want to receive

It was August.
I was on vacation, at SantoriniWhether for vacation or business, finally some relaxation after months of intense work. Sun, pool, stunning views, and finally that feeling of "switching off" you seek all year long. But, even though I was on vacation, I was never truly out of reach: The SmartWatch It was there on my wrist for that very reason, ready to alert me to any critical issues that colleagues, for whatever reason, were unable to address or that required my direct expertise.

That's why, when I see one coming direct call — not on the company number, but on my personal —I immediately understand that the situation could be serious.

On the other side there was the webmaster of an important client, one of those who invoice important figures online and that they can't afford downtime. His voice was tense and extremely worried:

Marco, the site does not work.

I'm stuck.

How does it not work?
He turns, turns, turns… but nothing happens.

The site in question was a PrestaShop 1.6. Old? Yes.
But for historical reasons for compatibility with a system ultra-complex custom — a configurator of signs, business cards, graphic compositions in real time — was tied to both PrestaShop 1.6 and PHP 5.6.
One of those installations that define delicate It's reductive: every modification, every anomaly, every slowdown... can mean a total blockage of the sales flow.

However, it's a leader in its sector—let's say the leader—in terms of speed, performance, and, above all, positioning. Its Google PageSpeed ​​rating is noteworthy, as shown in the image below.

A top-notch infrastructure, but that wasn't the problem

Now, let's be clear: this it wasn't just any hosting.
That PrestaShop, although dated, ran on a machine very respectable, dedicated server based on AMD Ryzen 5 3600X, 6 cores / 12 threads, 64 GB of RAM DDR4 e two mirrored discs OpenZFS to ensure redundancy, data integrity, and fast snapshots. All connected to a real 1 Gigabit connectivity, stable and constant, without bottlenecks or hidden limits.

And on top of that hardware, a software infrastructure designed for performances only:

• Zend Opcache configured by hand, optimized to squeeze every last CPU cycle.

• Advanced MySQL Tuning, the result of years of experiments, to better manage complex queries and large traffic volumes.

• Native Zstandard (zstd) compression — and no, no one else in Italy supports it without going through Cloudflare: we do this directly at the web server level, maximizing speed.

• Support a HTTP/3QUIC automatic fallback to HTTP/2, to always give the fastest response possible, regardless of the client's browser or network.

• Multiple compression Brotli, Zstandard, Gzip, , to ensure compatibility and performance in every scenario.

• OpenZFS file system automatic snapshots every 30 minutes, so you can go back in case of problems in seconds.

• Constant monitoring of performance and real-time alerts to prevent any degradation.

In short, the car was a engineering gemThere were no hardware bottlenecks, no configuration limitations, nothing was left to chance.

And yet… the site did not open.

At that point I get out of the pool, put the towel on my shoulders, go into the room in front of the pool itself, sit in front of the Notebook already turned on and I connect in SSH to the server via the excellent Termius.

I'll check the key parameters right away:

• CPU almost zero, no anomalous peaks.

• RAM free, no memory leak.

• MariaDB Database perfectly intact, online and responsive.

• Zpool ZFS healthy, no errors on the disks.

• Disk space more than sufficient, no risk of saturation.

In conclusion: on the system side everything was perfect.
The problem was elsewhere. But where?

Deep Dive: Where Standard Hosting Stops

Here comes the first substantial difference: on a classic hosting, at this point they would have already surrendered.
They would open a ticket, do a quick restart of Apache or Nginx, check two surface logs and, after a whole day, they would have answered you:

We checked, On the server side everything is okThe problem is with your site.

End of the story.
Website offline, customers lost, revenue frozen.

Not us. I I don't stopI keep digging.

First of all, restart Nginx. Nothing.
POI PHP-FPM. Nothing.
restarting all critical services of the server, one by one, and… still nothing.

At this point, I'm starting to think seriously:
“Ok, if it's not the server, it must be something at the application level. "

I'm staying on the phone with client's webmaster And let's try to think together. The next idea is to exploit one of the most powerful features we had available: OpenZFS.

Thanks to the fact that we use it on the server ZFS with automatic snapshots every 30 minutes, we have the chance to go back in time practically instantly. We're not talking about classic backups of hundreds of gigabytes that force you to stop for hours just to do a restore. No. Here we are talking about instant rollbacks, literally in a few seconds:

zfs rollback poolname/dataset@snapshot

This is the difference between a modern platform and "classic" solutions with daily backups. With ZFS we can test snapshot after snapshot, carefully selecting those snapped close to the moment when we know the site was working — cross-referencing the data with the timetable of the latest orders received.

Let's try a first rollback to the 12:00, the time when everything was definitely operational.
The recovery lasts a few secondsLet's test the site... does not work.

Ok, let's try half an hour earlier.
Same result: nothing to do.

We continue with several attempts, going back one snapshot at a time, but the site still doesn't respond.

This is a crucial step, because at this point we have two certainties:

1. It's not a server problem — the software stack and hardware are perfect.

2. It is unlikely to be an application issue, because even going back multiple snapshots to times when the site it definitely worked, the error persists.

We are therefore faced with something much more insidious.
It's neither the server's fault nor the application's fault.
The problem must be elsewhere.

The Breakthrough: Phantom Waiting MySQL Query

After all the failed attempts, I decide to log in directly to MySQL to understand what's really going on under the hood.
I open the session and run the command:

What I see leaves me puzzled.
I expect to find heavy queries, maybe some SELECT complex on huge tables, or a JOIN infinity that is monopolizing resources… and instead No..

This is what I find myself faced with:

• Many queries in “Sleep”

• No table specified

• No columns being processed

• No lines processed

Absolute silence.

The database he's not doing anythingIt's not crunching queries, it's not under stress, there's no competition between processes.

Yet those connections they stay there, suspended in a state of “semi-life”, waiting for something to happen.

What does it mean technically?

When MySQL shows you many connections “in Sleep”, with no active queries and no tables involved, it means just one thing:

1. PHP opens the connection to the database.

2. Send a query… but he doesn't actually do it.

3. Resta waiting for an external response.

4. Until that response arrives, the connection remains “open” and MySQL considers it “sleeping”.

Simply put: the problem is not MySQL.
It's not him who slows down. It's PHP that remains bloccato about something that has nothing to do with tables, indexes, or the structure of the database.

This is a case study that can waste hours for those who do not have a trained eye, because instinctively many, seeing "so many open connections", immediately think:

It's the database that's saturated.

But no.
There's no bottleneck inside the server here. It's not the load. It's not the memory. It's not the CPU. It's not the I/O. And it's not even the storage engine.

The hypothesis that changes everything

At this point the light bulb goes on in my head.
If PHP opens the query but never receives a response, it is waiting something that doesn't arrive.
And if it doesn't arrive, that “thing” is external to our stack.

A hypothesis begins to take shape:

What if these PHP scripts were waiting for a response from an external service who no longer responds?

To test this, I need to go the socket route.
I launch a netstat detailed and analyze the connections opened by the PHP-FPM process.
I find out that there are several calls to a recurring IP, in state of SYN_SENT: the connection starts, but never receives ACK.

I do a reverse DNS on that IP.
And there it is, the name that sets off alarm bells in my head:

dev.mypresta.eu.

When your site relies on someone else (and you don't know it)

I understand right away that here the critical point is found.
That domain, dev.mypresta.eu, it's not just any server: it belongs to a well-known PrestaShop module developer, quite widespread in the sector and used by thousands of e-commerce sites.

Checking the source code by running a grep, we find functions that make HTTP (and not HTTPS) calls to the server with hostname dev.mypresta.eu on port 80, and trying to simulate a web client, I decide to make a GET request to the hostname, which hangs for several seconds and then abruptly closes the connection without returning anything.

For this reason, the most plausible hypothesis, now almost a certainty, is that some modules installed on the site are trying to carry out an HTTP call to that server for:

• Check the validity of the license

• Check for any available updates

• Or download dynamic configuration information related to the module itself

And here comes a consideration crucial technique which many underestimate.

The problem of “blocking” calls

When a module or plugin uses a “blocking” HTTP call in PHP — for example via:

or

… E does not handle timeout correctly, this happens:

1. PHP sends the request to the external server.

2. Si farm e wait for the answer.

3. Until the answer comes, the execution it does not continue.

This wait may seem trivial, but it is a huge problem.
If the remote server unresponsive — as in this case, where dev.mypresta.eu was down — the call never fails immediately.

In the absence of an explicit timeout, PHP keeps the open connection up to global maximum timeout defined in the file php.ini or in the manager php-fpm.
Typically we talk about 30, 60, sometimes even 120 seconds of block.

Now imagine an e-commerce that receives hundreds of simultaneous requests.
Every single user who lands on the site goes through the offending module → PHP crashes → MySQL waits → all PHP-FPM workers saturate one after another.

The result?

• Requests start to stay in line.

• PHP process usage skyrockets to 100%.

• Even those who upload the home page or cart suffers the same delay, because the processes are monopolized by these calls.

• In a few minutes, the entire site becomes inaccessible.

The critical point: depending on what you don't control

This situation highlights a structural problem that I see often: Many websites depend on external endpoints without knowing it..

If a third-party service becomes slow, unstable, or unattainable, your site — which has no internal technical problems — collapses equally.
And this is where things get complicated, because the end customer, rightly, does not distinguish between an internal or external problem: for him, if the site doesn't work, the problem is with the hosting.

In fact, the site had become hostage of a single external endpoint that we didn't control and that, ironically, even the customer didn't know he was using it.

The emergency fix: where we make the difference

Here comes into play the competence.
There was no need to migrate, reinstall everything or do endless blind tests like a classic hosting would do, nor to wait for the endpoint to come back on (which was offline for more than 24 hours),
Once I identified the cause, I went directly in the incriminated modules and I have commented on the function file_get_contents() who contacted dev.mypresta.eu.
In this way I have completely bypassed the license verification, preventing PHP from getting stuck waiting for an external server that would never respond.

The result?
Website immediately online.

And not only that: by removing those blocking HTTP calls that were made recurrently by 2 modules from the same developer, il Time To First Byte of the site has improved by approximately 25-30%, saving as many as 3 remote HTTP GET calls. A significant gain, especially on an e-commerce site that works in real time and where every millisecond counts.

Total time from reporting to resolution: approximately 2 hours.
The call came in at the 14:00, and around the 16:00 the site was back up and running, billing and faster than before.

Now imagine the same scenario… on a hosting costing 50 or 100 euros per year

Let's do an exercise.
Imagine this customer if he wasn't with us, but on a classic hosting cPanel o Plesk standard, one of those “all-inclusive” ones that you find for 50 or 100 euros a year.

Do you know what would have happened?

• You would have opened a support ticket.

• They would have answered you A few hours later.

• They would have made a fast restart of services to "see if it starts again like this".

• They would have given a cursory glance at the logs.

• And, after a whole day, you would have received the classic response:

From our side, everything is fine, the problem is with the site.

The end. No insight. No solution. No applied expertise.

At that point, you — the customer — would have found yourself with an e-commerce completely blocked and you should have search alone a developer who understood the dynamics, who discovered the blocking call to dev.mypresta.eu, who would intervene on the code and restart the site.
We're talking about many hours, if not even days.
In the meantime, offline site, lost orders, customers abandoning, wasted revenue, Google scanning the site but not finding it online and penalizing you in the SERP or even making you disappear.

This thing is not a hypothesis: it is exactly what many people think, and I had confirmation of it a few days later.
I told this same story, in a confidential manner, its TikTok, without naming names or giving sensitive details.
Result? An avalanche of comments from other professionals — or so-called — who all claimed the same thing:

“These problems they do not concern hosting. "
“We here let's not get our hands dirty: it's developer stuff.”
“Open a ticket, but we can't help you. "

You can see some comments below, obviously anonymized for confidentiality reasons, but the concept is always the same:
for many hosting providers, when the problem it is not pure systemic, a rises Wall.

In short, the philosophy that can be perceived is:

“It’s not our responsibility, you sort it out.”

And it's exactly here that you can see the difference between a hosting from 50 euros per year and a service Managed like ours, we we don't stop at the edge of infrastructure.
When there is a problem that impacts your business if feasible, we'll solve it, even if the root is not "ours", in other cases we still identify it and report it to the customer.

The real value: we don't just sell hosting

And here we come to the crux of the matter, what does really the difference:
we We do not sell disk space, bandwidth, or panels.
We we sell expertise.

And mind you, I'm not talking about "generic skills," the kind you find everywhere at a low cost. I'm talking about real skills, of those that are built in decades of field experience, not following quick courses on YouTube or improvising as system administrators after installing two WordPresss.

When there is a serious problem, we we don't limit ourselves look at the system logs, say “the server is responding, so everything is OK” and pass the buck.
We dig. We analyze.
We follow every clue, make correlations, test hypotheses, understand where the chain breaks.
And especially, let's solve it.
Even when it's not "our fault".

The false illusion of low cost and hosting is still hosting.

Here many do not have the courage to be honest with customers: if you pay 50 or 100 euros per year for “general purpose” hosting, you can't have top-notch skills. IS mathematical.

Why?
Why true competence costs.
Cost in terms of years of training, real experience and, especially, people of the highest level.

You cannot expect a 4 euro per month service to provide you with a solution in times of crisis. champion who can do advanced MySQL debugging, blocking call analysis, kernel tuning, and hot patching of complex configurations.
Simply there is no economic margin to afford it.

And what do many cheap hosting companies do instead?
They put someone in front of you junior fresh out of college, or — and I have met several — a philosophy graduate turned computer scientist after a 200-hour course, paid with the wages provided for by the CCNL.
They are guys who maybe have enthusiasm, but they have no experience or method to deal with complex emergencies.

Now, the reality is harsh but simple: a true champion — the one that solves problems like that of dev.mypresta.eu in two hours — it doesn't cost 1.200 euros a month.
Top skills have costs comparable to those of a job at Google, Meta or Amazon.
And if you think you have them “included” by paying 50 euros a year… you are living an illusion.

Our model: excellence, not compromise

Our service is different by choice.
When a customer entrusts us with their e-commerce, their management system, their SaaS platform, we We don't treat it like one of 500 sites stacked on a discount store server.

• We don't put 500 sites on a single machine.

• We don't delegate debugging to a level 1 inexperienced that copies and pastes pre-packaged answers.

• We don't hide behind the phrase "it's not our responsibility."

We invest in people.
Real systems engineers. Software engineers. Database experts.
People who worked on complex architectures and who knows how to solve problems that others can't even diagnose.

This, inevitably, has a cost.
A service managed and cared for like ours can not e will never be able to cost the same as general purpose hosting costing 50 euros per year.
Not because “we like to charge more”, but because Excellence is not given away, but above all, excellence has a value.

A question of priority, not price

This is the difference between:

• Un cheap hosting, which costs 50 or 100 euros per year and puts an operator in front of you who follows a script.

• Un Managed service like ours, which costs 137 per month but it gives you direct access to those who really know how to solve problems.

It's not a question of "spending more."
It's a question of priority: do you want a hosting that keep your business online even in the most complex situations, or you just want some web space and a panel with two buttons?

Because the truth is this: if your site is important, if your turnover depends on it continuity of service, You can't delegate your online survival to someone who sells hosting at rock-bottom prices and has no expertise.

Conclusion: When your business is worth more than a coffee a day

There is an aspect that is often underestimated when talking about cheap hosting:
apparently, it works.
The site opens, the content is online, the emails are sent.
So the customer thinks, “That’s fine.”

But the reality is a little different.
Works, Yup, but worse than it could work.
And most people he has neither the expertise nor the tools to notice it.

What you don't see... costs you dearly

Let's take some concrete examples:

• MySQL or MariaDB database without tuning → queries that could be answered in 30 ms they put us 300 ms.

• Unoptimized PHP → your application does 5 times more calls than necessary, slowing everything down.

• Lack of appropriate caches → every time a user opens a page, the server redoes calculations that could be served instantly.

• Compression missing or obsolete → many cheap hostings don't even enable Gzip; Forget about it Brotli. And we, today September 7, 2025, are the only ones in Italy to offer ZSTD natively server-side, without the need for external proxies like Cloudflare.

• Default configurations → generic values ​​designed to “make everything work”, but not to perform at your best.

Now let's ask ourselves: does the average customer have the technical ability to understand that his site could go much faster?
Do you have the tools to analyze slow queries, check PHP execution times, check cache efficiency, and choose the best compression algorithm?
The answer, in most cases, is No..

The problem is that Everyone only notices quality when it is clearly lacking or the site is down.

All sailors in calm seas

As they say:

“All good sailors in calm sea. "

When everything seems to work, cheap hosting all right.
But what happens when it arrives? the storm?
What if your e-commerce site suddenly starts blocking orders, database queries explode, connections hang for minutes, customers start calling, and revenue stops?

There you don't need a fancy control panel, nor a "restart server" button in cPanel.
There is a need for someone there he knows what to do, which analyzes logs, cross-references data, identifies the problem and fixes it.
It is needed there a real systems engineer, not an automated script or a paid junior second CCNL that copies and pastes answers from an internal knowledge base.

The case I told you above is the perfect example:
a problem he didn't have nothing to do with the server, MySQL or PHP.
A problem that would have sent in total crisis any cheap hosting, because there the answer would have been:

“From our side, everything is fine. Contact your developer.”

But when you're with us, the problem is solved.
Whether it's a faulty module, an external endpoint that blocks everything, or a bug in the application: We don't stop at the wall of "it's not our responsibility".

At the risk of being repetitive: it's not a question of price, it's a question of priority.

If you have one personal blog, maybe you just need cheap hosting.
But if you have a e-commerce, CRM , online management or any platform on which your turnover depends, the question is not:

“How much does your hosting cost?”

The right question is:

“How much does every minute of downtime cost me? How much would it cost me if I lost everything?”

Because that's where the difference lies between a 50 or 100 euro per year service and a true Managed service, with people who they know how to solve problems before they overwhelm you.

And that's why we do things different.
That's why, when others tell you “it's not our problem”, we tell you instead:

“Okay, we’ll fix it.”

This is the difference between a simple hosting provider and an technical partner that helps you grow your business.