Ai nevoie de un server mai mare sau de o aplicație mai rapidă? Studiu de caz: Juridice.ro

Când ne-am uitat prima dată la infrastructura Juridice.ro, cifrele spuneau o poveste sumbră: serverul era blocat la 100% sarcină cu aproximativ 5.000 de cititori pe site. Vizitatorii vedeau încetiniri, erori și — în cele mai rele momente — un site care pur și simplu nu se încărca.

Astăzi, aceeași publicație servește de rutină peste 14.000 de cititori online, cu vârfuri peste 20.000, la aproximativ 35% sarcină.

De trei-patru ori traficul. O treime din sarcină. Aceasta este povestea cum s-a întâmplat — și de ce răspunsul nu a fost aproape niciodată „cumpără un server mai mare”.

Juridice.ro este una dintre cele mai mari și cunoscute resurse online pentru profesioniștii din drept din România, cu aproximativ 550.000 de vizite lunare conform SimilarWeb. Pentru o publicație al cărei întreg produs este să fie disponibilă când un avocat are nevoie de ea, fiecare încetinire costă putere de brand pe care nicio factură de server nu o poate răscumpăra.

Problema de 100%

Nu am cunoscut Juridice printr-un apel de vânzări. I-am găsit în timpul unui exercițiu de rutină de prospectare SEO — și am observat o publicație respectată care se lupta vizibil sub propriul succes. I-am contactat.

La acel moment, site-ul rula pe o platformă de hosting cu un OS și un stack web construite custom, unde — prin propria politică de acces a furnizorului — clienții nu primesc acces privilegiat la serverele lor. Printr-o neînțelegere legată de natura hosting-ului, Juridice credea că era pe hardware dedicat; în realitate, mașina era partajată și era plină.

Acea politică de acces a modelat prima noastră decizie majoră. În mod normal, instinctul nostru este să optimizăm înainte să mutăm — stoarcem întâi hardware-ul existent, cheltuim bani mai târziu. Aici, optimizarea pe loc era pur și simplu imposibilă: fără acces privilegiat, fără optimizare. Singura ușă era migrarea.

O mutare pe care nimeni nu a observat-o

Am propus un server dedicat la același buget pe care Juridice îl cheltuia deja — doar că acum banii cumpărau hardware real, un contract de servicii și o echipă care îmbunătățea activ platforma în loc doar să o găzduiască.

Migrarea în sine a fost proiectată pentru zero downtime. Am replicat totul în noul mediu, am pus pe pauză publicarea doar una-două ore cât s-a finalizat restaurarea bazei de date, apoi am comutat IP-urile. Noua locație a început să servească imediat, în timp ce cea veche a funcționat ca proxy, redirecționând întârziații al căror DNS încă nu se actualizase. Niciun cititor nu a văzut vreodată o pagină de mentenanță.

Mai rău înainte de mai bine

Iată partea pe care majoritatea studiilor de caz ar sări-o discret: imediat după migrare, sarcina era din nou peste 100%.

Stack-ul custom al vechii platforme fusese de fapt bine optimizat pentru ce era. Setup-ul standard cPanel pe care am aterizat — nginx în fața Apache — se descurca vizibil mai prost cu traficul Juridice. Schimbaserăm o mașină partajată plină cu una dedicată care rula un stack ce nu o putea folosi.

Prima noastră încercare de reparare a fost caching-ul de pagină nginx. A făcut lucrurile mai rapide — și a stricat ceva mai important: paginile nu se actualizau fiabil. Pentru o publicație care publică conținut juridic nou de mai multe ori pe zi, un cache care servește prima pagină de azi-dimineață e mai rău decât unul lent.

Așa că în câteva zile — și pe banii noștri — am mutat stack-ul pe LiteSpeed. Iar plugin-ul LiteSpeed Cache pentru WordPress a făcut, sincer, minuni: caching full-page care chiar înțelegea WordPress, invalidând corect când conținutul se schimba. Rapid și proaspăt.

Încă două straturi au completat fundația: fișierele statice au mers pe un CDN, pentru că vechiul setup servea imagini și resurse prin Apache mult prea des; și mai târziu, o curățare sistematică a traficului malițios de boți a mai tăiat 15% din sarcina totală — o bătălie care și-a câștigat propriul studiu de caz.

Succesul creează noi răufăcători

Apoi s-a întâmplat ceva interesant. Pe măsură ce resursele serverului se eliberau, site-ul devenea mai rapid — și pe măsură ce site-ul devenea mai rapid, numărul de vizitatori urca. Bucla de feedback pe care o speraserăm era reală: performanța hrănea creșterea.

Iar creșterea a stricat lucruri pe care nimeni nu le văzuse stricate înainte. Multe plugin-uri WordPress pur și simplu nu sunt proiectate pentru un site cu zeci de mii de cititori online. Lucrând împreună cu echipa tehnică a Juridice — și înarmați cu profilarea flamechart de la Datadog, care s-a dovedit a fi cel mai valoros instrument de diagnostic din tot proiectul — am vânat două dintre ele.

Răufăcătorul #1: plugin-ul de bannere. Plugin-ul folosit pentru a afișa bannere publicitare încărca întregul core WordPress de fiecare dată când număra o afișare. Și număra multe: rotatorul schimba bannerele la câteva secunde, înregistrând o nouă afișare la fiecare schimbare, pentru fiecare slot de banner de pe pagină. Un singur cititor, pur și simplu stând pe un articol, genera un flux constant de 2, 4, 10, uneori 20 de cereri WordPress complete — atâta timp cât continua să citească. Asta nu se scalează — se multiplică.

Soluția noastră interimară a fost un filtru WordPress care intercepta și bloca aceste cereri înainte să se declanșeze. În cele din urmă, un membru al echipei tehnice a Juridice a găsit răspunsul mai curat: o opțiune ascunsă în plugin pentru a dezactiva complet urmărirea afișărilor.

Răufăcătorul #2: contorul de utilizatori online. Acesta a fost o lecție de manual despre cum funcțiile mici devin probleme exponențiale. Plugin-ul care număra cititorii activi în acel moment stoca fiecare sesiune de citire în propriul tabel de bază de date — și scana întregul tabel la fiecare vizită. Mai rău, tabelul folosea motorul de stocare MyISAM, a cărui blocare la nivel de tabel forța tot traficul paralel al Juridice într-o singură coadă lentă. Cu cât veneau mai mulți vizitatori, cu atât tabelul era mai lung, scanarea mai lentă, coada mai lungă. Exponențial.

Convertirea tabelului la InnoDB a îmbunătățit lucrurile considerabil. Dar flamechart-urile continuau să vorbească: chiar și după conversie, 30–50% din timpul de execuție al aplicației era încă ars în interiorul acelui singur plugin. Așa că l-am retras și l-am înlocuit cu un mic serviciu custom scris în Go — construit special să numere cititorii online și nimic altceva.

Unde ne lasă asta

Fiecare limitator exponențial pe care l-am putut găsi a dispărut acum. La 14.000–20.000+ cititori online, serverul stă în jur de 35% sarcină, iar stack-ul se scalează liniar de aici: pe hardware-ul actual, fără alte modificări, ar trebui să suporte confortabil cel puțin de 2,5x traficul de azi — până la aproximativ 50.000 de vizitatori online citind site-ul în același timp.

Și nu am terminat. Construim și testăm în prezent un instrument intern numit Growl: un head de frontend simplificat pentru WordPress, scris în Go, cu toate fițele îndepărtate și caching total în memorie. Atinge baza de date doar la pornire și când un articol este actualizat. În testele noastre, aduce timpii de încărcare a paginii la câteva milisecunde și livrează un scor Google PageSpeed de 100% — iar pe hardware-ul actual al Juridice, ar trebui să se scaleze la ceva în jur de 10 milioane de vizitatori.

Dacă Growl performează în producție așa cum performează în testare, utilizarea CPU a Juridice scade sub 10% — posibil sub 5% — și RAM-ul sub 10%. Moment în care vom face o recomandare pe care nu o auzi des de la compania care îți gestionează serverele: downgrade.

Și încă ceva: intenționăm să lansăm Growl ca open source. Scăparea dintr-un lock-in nu ar trebui să însemne dobândirea altuia — nici față de un stack de hosting, nici față de noi.

De ce ne putem permite să spunem „downgrade”

Nu e niciun truc — doar design de stimulente. Juridice ne plătește un retainer fix. Profităm cel mai mult când totul rulează impecabil și nimeni nu trebuie să miște un deget; când lucrurile merg prost, noi pierdem bani. Un furnizor plătit la oră profită de pe urma problemelor. Un furnizor plătit după rezultat le vânează.

Această structură este motivul pentru care fiecare decizie din această poveste — mutarea stack-urilor pe banii noștri, înlocuirea plugin-urilor cu cod custom, construirea Growl, recomandarea de servere mai mici — punctează în aceeași direcție ca interesul clientului.

Concluzia principală

Upgrade-ul serverelor fără optimizarea performanței aplicației are randamente sever descrescătoare. Legile puterii te vor mușca mai rău, și mai rău, și mai rău — până îți strică petrecerea.

— Alexandru Eftimie, Helios Live

Problema originală a Juridice nu a fost niciodată cu adevărat o problemă de hardware. Un server mai mare cumpărat din prima zi ar fi mascat plugin-ul de bannere, contorul care scana tabelul și stratul de cache lipsă — exact până când traficul s-ar fi dublat și curbele exponențiale ar fi ajuns din urmă toate deodată, pe o factură mai mare.

Dacă sarcina serverului tău urcă mai repede decât traficul, acel raport este diagnosticul. Ceva din aplicația ta multiplică munca. Găsește-l înainte să plătești ca să-l hrănești.

Concluzie

De la 100% sarcină cu 5.000 de cititori pe site la 35% cu peste 20.000 în momentele de vârf. De la o mașină partajată fără acces root la un stack dedicat cu ambiții de milisecunde. De la „site-ul e iar picat” la „am putea sugera un server mai mic”.

Secvența care a adus Juridice aici — migrează pentru control, cache corect, profilează neobosit, ucide comportamentul exponențial, apoi reconstruiește calea critică — este acum modul în care abordăm fiecare publisher la scară. Hardware-ul a fost cea mai puțin interesantă parte a poveștii. De obicei este.