Magento Performance, Without the Made-Up Numbers
No invented benchmark charts here. What makes Magento fast on G7Cloud is simple and verifiable: dedicated RAM and CPU that are yours alone, PHP pre-tuned for Magento's codebase, a database on localhost and a managed Redis add-on.
The problem
Why Magento crawls on shared hosting
Magento is heavier than almost anything else in PHP. That is not a flaw — it is the cost of the flexibility that makes it worth running. But it punishes hosting that was sized for brochure sites.
The EAV database model
Magento stores product attributes across many tables. A single uncached product page can trigger dozens of joins — on a distant shared database server, each round-trip adds up fast.
A very large codebase
Tens of thousands of PHP files must be compiled and cached. With a default-sized OPcache, Magento constantly evicts and recompiles its own code — silently, on your customers' time.
Indexers compete with shoppers
Reindexing prices, stock and catalogue rules is CPU-hungry. On shared hosting your reindex fights every neighbour for the same cores — or worse, their batch jobs fight your checkout.
The admin panel is a workload too
Bulk product edits, report generation and imports hammer PHP and the database. If the same starved pool serves your admin and your customers, both lose.
The fix
What a dedicated container changes
Every Magento store on G7Cloud runs in its own container with hard RAM and CPU allocations. Nothing is shared with other customers — not PHP workers, not the web server, not the filesystem.
- Your RAM and CPU are yours: a neighbour’s traffic spike cannot slow your checkout
- Your reindex runs on your own allocation — it never queues behind someone else’s batch job
- MariaDB runs beside PHP in the same stack, so those EAV joins travel over localhost instead of a network hop to a shared SQL server
- 90 days of per-site CPU and RAM metrics in the dashboard show exactly what your store uses — capacity planning from data, not guesswork
# tuned for Magento, not generic PHP
memory_limit = 756M
opcache.memory_consumption = 512
opcache.max_accelerated_files = 60000
opcache.validate_timestamps = 0
# adjustable per site from the dashboard
A 512 MB OPcache with a 60,000-file ceiling means Magento's codebase stays compiled and hot. Timestamp validation is off in production, so PHP never wastes cycles re-checking files that have not changed.
RAM guidance
How much RAM your Magento store needs
Magento's own system requirements ask for 2 GB. Here is what each plan dedicates to your container, and what that honestly suits.
| Plan | Price | Dedicated RAM | Honest verdict | Suits |
|---|---|---|---|---|
| Business | £19/mo | 1 GB | Workable | Small catalogues (hundreds of SKUs), modest traffic, one or two admin users. Lean on Redis and full-page caching. |
| Pro | £39/mo | 2 GB | Recommended | Most Magento stores. Meets Magento's own 2 GB requirement with room for reindexing and admin work during trading hours. |
| Agency | £99/mo | 4 GB | Headroom | Large catalogues, several stores side by side, agencies managing client builds with team roles. |
Prices are fixed GBP — no usage billing. Compare every plan
What to point at Redis
- Session storage — logged-in customers and carts stop hitting MariaDB
- Backend cache — configuration, layout and block caches served from memory
- Full-page cache — Magento's built-in FPC backed by Redis keeps repeat page views off PHP and the database entirely
Caching
The managed Redis 7 add-on
Add a managed Redis 7 instance to your site from the dashboard — available on Business and above. The Redis PHP extension is already enabled in every Magento container, so wiring it up is a config change in env.php, not a support ticket.
This is the honest version of “Magento caching”: OPcache keeps the code hot, Redis keeps sessions and rendered content out of the database, and ScaleShield stops bots from generating expensive uncached requests in the first place.
We could show you a benchmark chart. We won't.
Hosting benchmarks are almost always synthetic, cherry-picked, or both. Your catalogue size, extensions and theme will dominate any number we could print here.
What we give you instead is the means to measure your own store: per-minute uptime monitoring with email, webhook and Slack alerts, and 90 days of CPU and RAM metrics per site. Migrate with our team, watch the graphs for a week, and judge us on your data. If it is not better, you have a 30-day money-back guarantee.
Related reading: how slow websites kill conversions.
FAQ
Performance questions, answered straight
Do you include Varnish?
No, and we would rather tell you that than imply otherwise. Magento's built-in full-page cache pointed at a managed Redis instance serves the large majority of stores well and is far simpler to invalidate correctly. If your store genuinely needs Varnish-level caching, talk to us before you migrate and we will tell you honestly whether we are the right fit.
Can I change PHP settings myself?
Yes. memory_limit, execution time and PHP extensions are adjustable per site from the dashboard, and you choose the PHP version your Magento release requires. The defaults are already Magento-appropriate: 756 MB memory_limit and a 512 MB OPcache with a 60,000-file ceiling.
What happens if my store hits its RAM limit?
The limit is hard — that is the point of dedicated containers. Nobody bursts into your memory and you cannot burst into theirs. The dashboard keeps 90 days of CPU and RAM metrics, so you will see the ceiling approaching well before it bites, and moving up a plan is a click, not a re-platform.
How do Magento cron and indexers run?
You schedule bin/magento cron:run from the dashboard's cron jobs feature, so indexers, catalogue price rules and transactional emails fire on time. You can also run reindexes by hand from the in-browser terminal.