De ce VPS-ul tău nou este mai lent decât shared hostingul și reparația exactă de 5 minute

Dacă VPS-ul tău este mai lent decât shared hostingul imediat după migrare, probabil serverul nu este mai slab. Vechiul shared host avea, cel mai probabil, caching, OPcache, workeri PHP, object cache, reguli de web server și valori implicite pentru bază de date deja tunate. VPS-ul nou poate avea CPU mai bun, mai mult RAM, storage SSD și acces root complet, dar nimic din asta nu contează dacă PHP-FPM are cinci workeri, OPcache lipsește, Redis nu este conectat, NGINX nu cache-uiește, MariaDB rulează pe valori implicite sau site-ul intră în swap. Prima reparație este o triere de 5 minute: verifică versiunea PHP, OPcache, RAM-ul, workerii PHP-FPM, Redis, page cache-ul și starea bazei de date înainte să dai vina pe VPS.

Aceasta este o problemă de panic-search. Ai migrat de pe shared hosting pe VPS pentru că te așteptai la mai multă viteză. Acum site-ul pare mai lent, clientul este nervos sau magazinul pierde comenzi. Adevărul neplăcut este că un VPS unmanaged proaspăt instalat poate performa mai slab decât un shared hosting bun până când cineva configurează corect stackul. Un VPS îți dă control. Nu îți dă automat tuning.

Dacă vrei ca stratul de server să fie gestionat de oameni care tunează stackuri de producție zilnic, începe cu găzduirea VPS ServerSpan sau predă problema către administrarea Linux ServerSpan. Dacă o repari singur, începe cu checklistul de mai jos.

Triage-ul de performanță VPS în 5 minute

Rulează aceste verificări înainte să modifici setări la întâmplare. Îți spun dacă problema este în PHP, memorie, cache, bază de date sau configurația web serverului.

php -v
php -m | sort | egrep 'opcache|redis|mysqli|curl|mbstring|xml|zip|imagick|gd'
php -i | egrep 'opcache.enable|opcache.memory_consumption|opcache.max_accelerated_files|opcache.validate_timestamps'
free -h
df -h
uptime
systemctl status php*-fpm --no-pager
systemctl status nginx apache2 mariadb mysql redis-server --no-pager 2>/dev/null
redis-cli ping 2>/dev/null
mysqladmin proc stat 2>/dev/null

Outputul expune de obicei problema rapid:

• Versiune PHP veche: ai migrat într-un runtime mai lent sau nesuportat.
• OPcache lipsește sau este dezactivat: PHP recompilază scripturile în loc să folosească bytecode cache-uit.
• Memorie liberă puțină sau swap folosit: VPS-ul este subdimensionat sau configurat greșit.
• PHP-FPM este oprit sau subdimensionat: cererile stau la coadă sau eșuează.
• Redis nu răspunde: object cache-ul persistent nu este activ.
• MariaDB este supraîncărcat: interogările în baza de date sunt blocajul.
• Nu există page cache: fiecare vizitator anonim lovește PHP și MySQL.

Nu sări direct la cumpărarea unui VPS mai mare. Un VPS mai mare, dar netunat, rămâne tot netunat. În experiența noastră cu tichetele de tip „serverul meu este lent”, cele mai rapide câștiguri vin de obicei din OPcache, dimensionarea workerilor PHP-FPM, Redis object cache, NGINX FastCGI cache și eliminarea presiunii pe swap.

Reparația 1: verifică dacă PHP este actual și OPcache este activ

Începe cu PHP. Performanța WordPress depinde masiv de runtime-ul PHP. Handbookul oficial WordPress de performanță indică explicit versiunile software curente, optimizarea PHP, OPcache, cachingul web serverului și optimizarea bazei de date ca pârghii majore de performanță. Tabelul oficial PHP cu versiuni suportate arată ce ramuri sunt încă în zona sigură în 2026, iar versiunile vechi ies rapid din traseul sănătos de mentenanță.

php -v
php -i | grep 'opcache.enable'
php -i | grep 'opcache.memory_consumption'
php -i | grep 'opcache.max_accelerated_files'

Dacă OPcache este dezactivat, activează-l. Documentația oficială PHP pentru OPcache listează opcache.enable ca activ implicit și opcache.memory_consumption cu valoare implicită de 128 MB, dar imaginile VPS, buildurile de panel și instalările custom pot varia. Nu presupune. Verifică.

Pentru un VPS WordPress sau WooCommerce normal, începe cu:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Pe Debian sau Ubuntu cu PHP-FPM, fișierul este de obicei într-o cale de forma:

/etc/php/8.3/fpm/conf.d/10-opcache.ini
/etc/php/8.3/fpm/php.ini

Repornește PHP-FPM după modificări:

systemctl restart php8.3-fpm

Dacă folosești DirectAdmin sau cPanel pe VPS, selectează mai întâi versiunea PHP din panel, apoi verifică din shell. Versiunea PHP aleasă în panel și binarul PHP din CLI nu sunt întotdeauna același lucru. Diferența asta duce la depanare leneșă și concluzii greșite.

Reparația 2: tunează workerii PHP-FPM în loc să înfometezi site-ul

Un VPS nou are adesea valori PHP-FPM conservatoare. Este sigur, dar poate fi lent. Dacă pm.max_children este prea jos, vizitatorii așteaptă la coadă chiar dacă VPS-ul încă are CPU liber. Dacă este prea sus, VPS-ul rămâne fără RAM și Linux începe să omoare procese sau să folosească swap agresiv.

Găsește poolul activ:

grep -R "pm.max_children" /etc/php/*/fpm/pool.d/

Măsoară memoria medie PHP în timpul traficului real:

ps -ylC php-fpm8.3 --sort:rss
ps -o rss= -C php-fpm8.3 | awk '{sum+=$1; n++} END {if (n>0) print "avg MB:", sum/n/1024}'

Folosește acest calcul aproximativ:

pm.max_children = RAM disponibil pentru PHP / dimensiunea medie a unui proces PHP-FPM

Exemplu: un VPS de 4 GB cu 1,5 GB rezervați pentru OS, MariaDB, Redis și buffere lasă aproximativ 2,5 GB pentru PHP. Dacă fiecare copil PHP-FPM folosește aproximativ 70 MB, o valoare rezonabilă pentru pm.max_children este în jur de 35.

pm = dynamic
pm.max_children = 35
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500

Repornește PHP-FPM după editare:

systemctl restart php8.3-fpm

Insight operațional: pe un VPS mic cu WooCommerce, de obicei rămâi fără workeri PHP înainte să rămâi fără CPU brut. Oamenii văd load average mic și presupun că serverul este în regulă. Între timp, PHP-FPM nu mai are copii liberi și cererile așteaptă.

Reparația 3: adaugă Redis object cache dacă vechiul host îl avea

Multe platforme bune de shared hosting includ discret object caching sau rulează straturi de bază de date tunate în spate. VPS-ul tău poate să nu aibă nimic din asta. WordPress explică faptul că object cachingul persistent grăbește încărcarea paginilor prin reducerea acceselor repetate la baza de date. Fără el, web serverul citește iar și iar opțiuni și alte date din MySQL sau MariaDB la fiecare page view.

Verifică Redis:

redis-cli ping

Dacă Redis rulează, răspunsul așteptat este:

PONG

Instalează Redis dacă lipsește:

apt update
apt install redis-server php-redis
systemctl enable --now redis-server
systemctl restart php8.3-fpm

Apoi instalează un plugin WordPress pentru Redis object cache și activează-l din WordPress admin sau WP-CLI. Serviciul de server singur nu este suficient. WordPress trebuie să folosească efectiv Redis.

wp plugin install redis-cache --activate
wp redis enable
wp redis status

Dacă nu ai WP-CLI, activează-l din interfața pluginului. Apoi verifică statusul pluginului. Un serviciu Redis care rulează, dar nu este conectat la WordPress, îți dă încredere falsă fără performanță.

Reparația 4: refă page cache-ul sau FastCGI cache-ul

Acesta este cel mai comun motiv pentru care un shared host pare mai rapid decât un VPS nou. Vechiul host putea avea page cache la nivel de server, LiteSpeed Cache, NGINX FastCGI cache, Varnish sau un plugin de caching bine configurat. VPS-ul nou poate servi fiecare cerere anonimă de pagină prin PHP și MariaDB.

WordPress arată că pluginurile de caching pot servi fișiere statice și pot reduce sarcina de procesare, iar cachingul la nivel de server poate servi pagini pregenerate fără să execute întregul lanț web server, PHP și WordPress. Modulul FastCGI din NGINX documentează fastcgi_cache, dar cachingul nu apare magic dacă nu îl configurezi.

Verifică dacă NGINX expune status de cache. Unele stackuri adaugă un header de forma:

curl -I https://example.com | egrep -i 'cache|x-cache|fastcgi'

Dacă nu există page cache, instalează un plugin WordPress de caching serios sau configurează NGINX FastCGI cache. Pentru NGINX, o zonă de cache de bază începe așa:

fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

Apoi, în locația PHP, aplică cache-ul cu atenție:

fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 301 302 60m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-FastCGI-Cache $upstream_cache_status always;

Nu cache-ui orbește paginile de coș, checkout, cont, utilizatorii autentificați sau cererile cu cookie-uri de sesiune WooCommerce. O regulă proastă de cache poate expune conținut specific utilizatorului. Lipsa totală a cache-ului face VPS-ul lent. Regula corectă stă între aceste două greșeli.

Reparația 5: verifică MariaDB înainte să dai vina pe web server

Un site WordPress poate arăta ca o problemă PHP când blocajul real este MariaDB. După migrare, valorile implicite ale bazei de date pot fi prea mici, indexurile pot fi învechite, pluginurile pot rula interogări grele sau baza de date poate concura cu PHP pentru RAM.

Începe cu:

mysqladmin proc stat
mysqladmin extended-status | egrep 'Threads_connected|Threads_running|Slow_queries|Questions|Queries'
systemctl status mariadb --no-pager

Documentația MySQL descrie mysqladmin ca un client pentru operațiuni administrative, inclusiv verificarea statusului serverului, afișarea threadurilor active și afișarea unui scurt mesaj de status. Folosește-l pentru că oferă semnal rapid în timpul panicii.

Dacă vezi multe interogări lungi, activează temporar slow query log:

mysql -e "SET GLOBAL slow_query_log = 'ON';"
mysql -e "SET GLOBAL long_query_time = 1;"

Apoi urmărește calea de slow log configurată de pachetul tău MariaDB. Pe sisteme Debian-based, începe prin a verifica:

grep -R slow_query_log /etc/mysql/ /etc/my.cnf* 2>/dev/null
tail -f /var/log/mysql/mariadb-slow.log 2>/dev/null

Dacă slow logul se umple imediat, VPS-ul nu este „lent” în general. Workloadul de bază de date este lent. Redis object cache, curățarea pluginurilor, optimizarea interogărilor și dimensionarea corectă a bufferelor MariaDB vor ajuta mai mult decât încă două vCPU.

Memoria și swapul: ucigașul tăcut al VPS-ului

Shared hostingul ascunde managementul memoriei. VPS-ul îl expune. Dacă noul VPS are 1 GB RAM și ai instalat NGINX, PHP-FPM, MariaDB, Redis, scanare malware, backupuri, monitorizare și un control panel, s-ar putea să rămâi fără memorie înainte să apară traficul real.

free -h
swapon --show
vmstat 1 5
dmesg -T | egrep -i 'killed process|out of memory|oom'

Dacă swapul este activ sub trafic normal, site-ul va părea lent aleatoriu. Dacă OOM killer apare în dmesg, Linux omoară procese pentru că memoria este epuizată. Asta nu este o problemă de caching. Este o problemă de dimensionare sau configurație.

Pentru WordPress mic, 2 GB RAM este un punct de pornire mai realist decât 512 MB dacă serverul rulează și MariaDB și Redis. Pentru WooCommerce, 4 GB este un prag mai sănătos. La ServerSpan, asta înseamnă de obicei vm.Ready pentru site-uri mici de producție și vm.Steady pentru WooCommerce, WordPress mai greu, Redis, backupuri și monitorizare. Prețurile nu includ TVA.

De ce vechiul shared host părea mai rapid

Un shared hosting bun nu este doar un director pe un server. Include adesea PHP tunat, OPcache, cache la nivel de web server, servire eficientă a fișierelor statice, tuning de bază de date, reguli anti-malware, rutine de backup și un panou de control care ascunde complexitatea. Ai plecat de la limitele platformei, dar ai plecat și de la tuningul platformei.

De aceea „specificațiile mai bune” pot pierde în fața unei configurații mai bune. Un VPS cu 4 vCPU și fără cache poate pierde în fața unui shared host cu page cache. Un VPS cu 6 GB RAM poate părea lent dacă PHP-FPM are cinci workeri. Storage-ul NVMe nu compensează o interogare de bază de date care rulează de 400 de ori pe pagină. Accesul root nu activează singur OPcache.

Upgradeul real nu este shared hosting către VPS. Upgradeul real este shared hosting către un VPS tunat corect.

Reparația exactă de 5 minute, în ordine

Dacă ai nevoie de cea mai scurtă listă posibilă de acțiuni, fă asta:

1. Verifică versiunea PHP și treci la PHP 8.3 sau 8.4 dacă site-ul o suportă.
2. Activează OPcache și ridică opcache.memory_consumption la 256 MB.
3. Verifică pm.max_children și crește-l în funcție de RAM-ul real și dimensiunea proceselor.
4. Instalează și conectează Redis object cache pentru WordPress.
5. Activează page cache printr-un plugin WordPress de cache sau prin NGINX FastCGI cache.
6. Verifică mysqladmin proc stat pentru presiune pe bază de date.
7. Verifică free -h, swapul și logurile OOM înainte să presupui că ai nevoie de mai mult CPU.

Este mai mult decât o singură comandă, dar este cea mai rapidă cale onestă. Varianta necinstită este „fă upgrade la RAM” sau „instalează un plugin de cache” fără diagnostic. Uneori ajută, dar pierde timp când problema reală este în workerii PHP, OPcache, Redis, interogări de bază de date sau swap.

Când reparația nu durează 5 minute

Unele probleme nu sunt simple greșeli de configurație. Acestea cer lucru mai profund:

• o temă WordPress umflată care încarcă sute de asseturi
• prea multe pluginuri care creează opțiuni autoloaded
• tabele WooCommerce cu indexuri lipsă sau foarte mult order metadata
• apeluri API externe care blochează randarea paginii
• malware care injectează cod lent
• joburi de backup care rulează în timpul traficului de vârf
• optimizare de imagini sau regenerare de thumbnailuri care saturează CPU-ul
• arhitectură greșită de web server după migrare

Aici ajutorul profesionist este mai ieftin decât ghicitul. Dacă site-ul contează, folosește administrarea serverelor Linux în loc să transformi producția într-un laborator.

Shared hostingul poate fi în continuare răspunsul corect

Fii sincer în privința situației tale. Dacă rulezi un site mic de prezentare, un portofoliu sau un blog liniștit, un plan bun de găzduire web poate fi mai potrivit decât un VPS unmanaged. Panelul, mailul, SSL-ul, backupurile, PHP-ul și cachingul sunt deja împachetate pentru tine.

Un VPS are sens când ai nevoie de control, scalare, Docker, software custom, staging izolat, Redis, worker queues, capacitate WooCommerce sau troubleshooting la nivel root. Dacă nu vrei să administrezi aceste componente, alege VPS managed sau rămâi pe shared hosting bun. Nu cumpăra infrastructură pe care nu ești pregătit să o operezi.

Calea ServerSpan recomandată după o migrare VPS lentă

Dacă tocmai ai migrat și VPS-ul este mai lent decât shared hostingul, nu cumpăra panicat cel mai mare plan. Mai întâi identifică dacă blocajul este cache-ul, workerii PHP, baza de date, memoria sau discul. Apoi alege calea corectă:

• Site WordPress mic: shared hosting sau vm.Ready dacă ai nevoie de root access.
• Site WordPress de business: vm.Ready cu PHP-FPM, OPcache, Redis și backupuri configurate corect.
• WooCommerce sau WordPress greu: vm.Steady ca prag mai sănătos.
• Mai multe site-uri, staging, monitorizare și workeri în fundal: vm.Steady sau vm.Go.
• Fără timp de sysadmin: VPS managed plus suport de administrare Linux.

Planurile VPS ServerSpan includ opțiuni KVM cu acces root complet, resurse dedicate, storage SSD, IPv4, IPv6, protecție DDoS și locații de datacenter în SUA, Canada și Germania. Hardware-ul nu este partea grea. Partea grea este să faci stackul să se comporte corect sub trafic real.

Lecturi conexe înainte să mai schimbi ceva

Dacă încă decizi dacă VPS-ul a fost alegerea corectă, citește Shared hosting vs VPS: de ce ai nevoie cu adevărat în 2026?. Dacă vrei perspectiva de suport asupra plângerilor vagi de performanță, citește Realitatea tichetelor de tip „serverul meu merge greu”. Dacă problema este specific WordPress în spatele NGINX și PHP-FPM, citește WordPress 502 Bad Gateway în 2026.

Răspunsul practic

VPS-ul tău nou este probabil mai lent decât shared hostingul pentru că shared hostul avea valori implicite optimizate, iar VPS-ul are resurse brute fără tuning. Repară stackul în această ordine: versiune PHP, OPcache, workeri PHP-FPM, Redis object cache, page cache, stare MariaDB, memorie și swap. Un VPS nu este automat mai rapid. Un VPS tunat este mai rapid, mai controlabil și mai ușor de scalat.

Dacă vrei rezultatul acesta fără să devii sysadmin, începe cu găzduire VPS managed de la ServerSpan și folosește administrarea Linux când problema cere tuning hands-on. Reparația nu este magie. Este configurație.