Cum am optimizat un backend în Go pentru a gestiona peste 460 de cereri/secundă pe un VPS minimal

Când construim aplicații web cu un nivel ridicat de concurență, reacția reflexă la apariția unui blocaj de performanță este aproape întotdeauna cumpărarea de hardware mai scump. Cu toate acestea, ca ingineri software, trecem adesea cu vederea cât de multă performanță brută poate fi stoarsă din infrastructuri minimale prin optimizarea atentă a codului și calibrarea corectă a sistemului.

Recent, am supus un serviciu de știri dezvoltat în Go unei serii agresive de teste de stres folosind Artillery, trimițând un volum masiv de 10.000 de cereri concurente pentru a găsi plafonul absolut al arhitecturii noastre.

Iată o analiză detaliată a modului în care am transformat o mică instanță de test de tip single-core într-un mediu dual-core gata de producție, izolând blocajele de la nivelul bazei de date, logicii aplicației și stivei de rețea Linux.

🏗️ Infrastructura sub lupă Procesul nostru de benchmarking s-a concentrat pe evaluarea modului în care același cod de aplicație în Go scalează pe două configurații de Server Virtual Privat (VPS) complet diferite:

„Mula” (Serverul de Test): 1 nucleu CPU, 2 GB RAM, 2 GB Swap, stocare SSD standard de 25 GB.

„Mașina de Curse” (Serverul de Staging/Producție): 2 nuclee CPU, 8 GB RAM, stocare NVMe de mare viteză de 100 GB, configurat în spatele unui proxy invers Nginx.

Ținta testului a fost un endpoint de tip /news, încărcat cu articole complete, metadate de paginare și URL-uri de imagini.

📈 Evoluția Benchmark-urilor și Rezultatele Testelor Am rulat mai multe iterații folosind Artillery (npx artillery quick --count 200 --num 50) pentru a genera 200 de Utilizatori Virtuali (VUs) concurenți, fiecare trimițând câte 50 de cereri rapide, însumând 10.000 de cereri per test.

Testul 1: Testarea plafonului aplicației (VPS Test, 1 CPU) Mai întâi, am ridicat complet limitele de trafic (rate limiting) pe micul server de test pentru a vedea cum gestionează runtime-ul procesarea brută, fără filtre intermediare.

Total cereri: 10.000

Rată de transfer (Throughput): 217 cereri/secundă

Latența mediană (p50): 788,5 ms

Latența maximă (p99): 1.130,2 ms

Rată de succes: 100% (0 conexiuni pierdute sau erori de server)

Analiză: Mașina cu 1 singur CPU a demonstrat eficiența incredibilă a schedulerului de goroutine din Go. Nu a pierdut nicio cerere. Totuși, deoarece runtime-ul Go și PostgreSQL se luptau pentru același nucleu fizic, sistemul a suferit din cauza supraîncărcării cauzate de schimbarea de context (context-switching) și de epuizarea pool-ului de conexiuni la baza de date, ceea ce a urcat latența mediană la aproape 800 ms.

Testul 2: Avantajul optimizării prin paginare Am încărcat endpoint-ul cu date considerabil mai grele (corpuri extinse de text și array-uri de imagini), dar am impus o structură curată de paginare la nivelul bazei de date (LIMIT / OFFSET).

Total date transferate: A crescut de la 74,1 MB la 108,3 MB (+46%)

Rată de transfer (Throughput): A urcat la 291 cereri/secundă (+34%)

Latența mediană (p50): A scăzut la 671,9 ms

Rată de succes: 100%

Analiză: În mod paradoxal, deși am transferat mai multe date, execuția a fost mai rapidă. Prin paginarea endpoint-ului, am înlocuit scanările secvențiale grele din Postgres cu interogări ușoare, bazate pe indecși. Acest lucru a redus timpul în care Go stătea blocat așteptând conexiuni din pgxpool, lăsând aplicația liberă să transmită bufferele JSON către interfața de rețea mult mai eficient.

Testul 3: Migrarea pe serverul cu 2 CPU (Zidul Nginx) Am mutat aplicația pe configurația mai puternică, cu 2 CPU / 8 GB RAM, în spatele Nginx. La prima rulare, am lovit o barieră dură de rețea.

Rată de transfer (Throughput): S-a stabilizat la 452 cereri/secundă

Latența mediană (p50): A scăzut brusc la 194,4 ms

Erori: ❌ 49 de timeout-uri de socket (ERR_SOCKET_TIMEOUT)

Analiză: Deși nucleul CPU suplimentar a redus latențele de aproximativ 3,8 ori, serverul a început să întrerupă conexiunile sub un flux masiv de trafic. Blocajul nu mai era codul nostru în Go, ci limitele implicite ale proceselor worker din Nginx și lipsa unui cache pentru sesiunile SSL, ceea ce forța serverul să consume cicluri CPU prețioase re-calculând handshake-uri criptografice grele pentru fiecare cerere.

Testul 4: Stiva complet optimizată Am ajustat parametrii Nginx (worker_connections 4096, keepalive_requests 10000) și am implementat un cache partajat în memorie pentru sesiunile SSL (ssl_session_cache shared:SSL:10m).

Metricile raportului final vorbesc de la sine:

Summary report @ stiri.digital/news

http.codes.200: ................................................................ 6700 http.request_rate: ............................................................. 466/sec http.response_time: min: 49 ms max: 652 ms mean: 147,3 ms median: 141,2 ms p95: 223,7 ms p99: 273,2 ms Rată de transfer (Throughput): Vârf susținut de 466 cereri/secundă

Latența mediană (p50): Un rezultat excelent de 141,2 ms

Latența maximă (p99): Menținută stabil sub 273,2 ms

💡 Concluzii Arhitecturale Cheie Acest flux de lucru oferă trei reguli critice pentru inginerii de backend care doresc să construiască sisteme performante pe infrastructuri accesibile ca preț:

Cea mai rapidă interogare este cea pe care nu o faci niciodată: Dacă datele se schimbă rar, servirea răspunsurilor direct din memoria cache a Go (In-Memory Cache) ocolește complet baza de date, permițând chiar și unei mașini cu 1 CPU să gestioneze mii de cereri pe secundă.

Calibrați corect pool-ul de conexiuni: Pe hardware limitat, lăsând instrumente precum pgxpool pe setările implicite riscați să înfometați aplicația. Restricționarea conexiunilor maxime la un număr strâns și stabil (de exemplu, 25 pe 1 CPU, 50 pe 2 CPU) previne colapsul bazei de date sub greutatea schimbărilor de context.

Nu ignorați kernelul sistemului de operare: Atunci când testați volume mari de concurență, cozile de rețea din kernelul Linux (somaxconn și tcp_max_syn_backlog) sau limitele de procese din Nginx sunt adesea vinovații tăcuți din spatele timeout-urilor de socket – nu logica aplicației.

Concluzie: Limba Go oferă dezvoltatorilor o fundație incredibil de puternică pentru a construi sisteme rapide și fiabile. Atunci când este combinat cu o paginare structurată a bazei de date și un proxy invers configurat corect, un server modest cu 2 CPU poate face față cu brio cerințelor de producție ale unei aplicații de știri cu trafic intens, la o fracțiune din costurile standard de găzduire în cloud.