De ce un server de 8 ori mai mic a făcut Vitacom mai rapid

Când un magazin Magento devine lent, prima soluție e de multe ori un server mai mare. Al Vitacom ajunsese la 64 de nuclee și 256 GB de RAM și tot răspundea în 15.814 ms. Azi, același magazin rulează pe 8 nuclee și 32 GB și răspunde în 12 ms. Sunt rezultatele care au câștigat Best Performance Improvement la HIVE Germany 2026.

Iată de ce serverul mai mare nu a ajutat, ce am schimbat și în ce ordine, și ce să verifici înainte să plătești pentru mai mult hardware.

De ce mai multe nuclee nu fac o pagină mai rapidă

PHP tratează fiecare cerere de pagină într-un singur proces, pe un singur nucleu. O pagină care are nevoie de 15 milioane de operații în baza de date durează la fel de mult pe un server cu 64 de nuclee ca pe unul cu 8. Nucleele în plus doar lasă mai multe cereri lente să ruleze în paralel. Îți cumpără loc pentru mai mulți clienți care așteaptă, nu o așteptare mai scurtă.

Viteza vine din mai puțină muncă pentru fiecare pagină și din a nu o mai face deloc când răspunsul e deja cunoscut. La asta servește cache-ul de pagini: Varnish păstrează o copie gata făcută a fiecărei pagini și o servește în câteva milisecunde, fără să pornească PHP și fără să atingă baza de date.

Ce făceau cele 64 de nuclee

La auditul nostru din noiembrie 2025, fiecare pagină mergea până la baza de date:

• Varnish era instalat, dar ocolit. Antetele greșite țineau paginile în afara cache-ului, așa că fiecare vizită pornea din nou PHP.
• 290+ module rulau la fiecare pagină fără cache, cu până la 15 milioane de operații în baza de date pentru o singură pagină.
• Baza de date nu era reglată pentru Magento și avea aproximativ 2,4 GB în două tabele de loguri.
• Nu existau Redis și RabbitMQ, așa că cache-ul, sesiunile și cozile de mesaje foloseau variante mai lente.

Serverul fusese mărit ca să țină pasul. A ținut magazinul în picioare, dar nu putea face o pagină mai rapidă.

Ce am schimbat, în ordinea asta

1. Februarie 2026, un server făcut pentru Magento. Varnish în față, apoi Nginx și PHP-FPM, Redis pentru cache și sesiuni, RabbitMQ pentru cozi, o bază de date reglată pentru Magento și toate patch-urile de securitate lipsă. L-am dimensionat la 16 nuclee și 32 GB, cu rezervă intenționat, cât timp învățam magazinul. În ziua lansării, aceeași pagină din admin se încărca de două ori mai repede decât pe serverul vechi.
2. Martie 2026, mai puțină muncă. ElasticSuite a înlocuit 32 de module de căutare, filtre și merchandising, iar Magento a trecut la 2.4.8. Încărcarea procesorului bazei de date a scăzut, în medie, la o treime.
3. Noaptea de 19 mai 2026, Liquid Framework și Hyvä Checkout. Procesorul bazei de date, care stătea între 200% și 350% (1 vCPU = 100%), a coborât imediat după lansare și a rămas de cele mai multe ori sub 50%. Abia atunci am mutat magazinul pe 8 nuclee.

Ordinea contează. Dacă micșoram întâi serverul, un magazin lent devenea și mai lent. Scoțând întâi munca, serverul mai mic a fost suficient.

12 milisecunde înseamnă cache-ul care răspunde

Cele 12 ms sunt Varnish care servește o pagină de produs din cache. Cele 15.814 ms erau serverul vechi care construia de la zero pagina principală. Sunt pagini diferite, dar ambele sunt teste de viteză pe magazinul live și măsoară cât așteaptă clientul până la primul byte.

Un cache ajută doar dacă paginile ajung chiar în el. Vitacom are trei magazine (retail, B2B și export) și clienți business care se loghează. Fiecare produs e păstrat acum în 24 de versiuni în cache: una pentru vizitatori și câte una pentru fiecare dintre cele 7 grupuri de clienți, pe fiecare dintre cele 3 magazine. Și un client business logat primește o pagină din cache. Paginile de cont și checkout-ul sunt personale, așa că nu intră niciodată în cache.

Clienții reali văd mai mult de 12 ms, pentru că propria lor rețea adaugă timp. Explicăm diferența în Scorul PageSpeed sau clienții reali. Iar modulele scoase au tăiat și factura de extensii: până la 31.500 EUR pe an din licențe.

Cinci verificări înainte să cumperi un server mai mare

1. Încarcă de două ori aceeași pagină de produs, ca vizitator. Dacă a doua oară răspunsul tot durează secunde, paginile nu vin din cache. Cu configurația Varnish standard a Magento, antetul de răspuns X-Magento-Cache-Debug spune HIT sau MISS.
2. Verifică app/etc/env.php. Secțiunile de cache și de sesiuni ar trebui să numească Redis, iar cea de cozi, RabbitMQ (amqp).
3. Uită-te la cele mai mari tabele din baza de date. Tabelele de loguri și rapoarte de ordinul gigabyților arată că nu le curăță nimeni.
4. Numără modulele care rulează pe paginile de produs. Verificările din Hyvä nu a fost niciodată problema iau o după-amiază.
5. Urmărește procesorul bazei de date, nu doar pe al serverului. Dacă baza de date ține ocupate câteva nuclee la un trafic obișnuit, problema e munca de pe fiecare pagină, nu mărimea mașinii.

Pe Magento și Hyvä

În Liquid Framework, cache warmer-ul reumple Varnish în fundal, prin RabbitMQ, ori de câte ori se schimbă un produs, o categorie sau o pagină, ca următorul client să nu primească o copie lentă, fără cache. Imaginile produselor stau și ele în cache-ul Varnish și se curăță automat când salvezi un produs.

Te gândești la un server mai mare? Programează întâi un apel de strategie gratuit. Ne uităm împreună la cache, la încărcarea bazei de date și la lista de module și îți spunem dacă serverul e cu adevărat problema.