Test de încărcare Apache și Tomcat pe un VPS: blocaje și rezultate
Data publicării:
Actualizat:
Articole tehnice > Test de încărcare Apache și Tomcat pe un VPS: blocaje și rezultate
Contextul din 2026 și utilizarea în siguranță
Concluzie: într-o stivă Apache-to-Tomcat, prima limită poate fi clientul, lucrătorii proxy, firele de execuție a conectorului, heap JVM sau colectarea gunoiului, codul aplicației, baza de date sau VPS-ul însuși. Un singur număr de concurență nu poate identifica capacitatea fără latență, eroare și dovezi privind resursele.
Ce vei învăța
- Ce a măsurat experimentul VPS inițial pe două niveluri.
- Cum interacționează limitele proxy și conectorul Tomcat cu timpul de răspuns al aplicației.
- Ce să înregistrați într-un test modern: percentile, debit, eșecuri, procesor, memorie, GC, fire și saturație în aval.
Cui se adresează: echipele web Java învață cum să proiecteze un test de capacitate mic, bazat pe dovezi.
Contextul din 2026: Rezultatele de mai jos aparțin testului original al autorului și nu au fost reproduse pentru această actualizare editorială. Tratați-le ca un studiu de caz, performanță actuală neverificată sau o recomandare de cumpărare VPS.
Notă de siguranță: comenzile și exemplele de configurare din articolul original nu au fost reluate într-un mediu de producție actual. Verificați versiunile acceptate, copiile de rezervă, controalele de acces și pașii de retragere într-un mediu de testare separat înainte de a le aplica.
Surse oficiale principale
Prezentare generală
Am măsurat numărul maxim de cazuri pe care serverele WEB/AP (Apache și Tomcat) le pot procesa în același timp și aș dori să scriu despre rezultatele obținute. Am fost curioși să aflăm care este numărul maxim de cereri care pot fi servite, așa că am efectuat un sondaj. Folosiți-o ca referință pentru a selecta specificațiile serverului VPS.
De data aceasta, măsurătorile au fost efectuate pe serverele WEB/AP (Apache și Tomcat), dar vă rugăm să consultați articolul de mai jos pentru măsurători doar pe WEB (Apache).
Cuprins
1. măsurare
1-1. Mediul de măsurare
În continuare este prezentat mediul în care se vor efectua măsurătorile.
■Informații despre serverul de închiriere
| CPU | 2core |
|---|---|
| memory | 1GB |
| SSD | 50GB |
■Informații despre server
| OS | CentOS 7.4 64bit |
|---|---|
| Server web | Apache HTTP Server 2.4.41 |
| Server AP | Apache Tomcat 9.0.27 |
| Server DB | PostgreSQL 10.2 |
| Java | OpenJDK 11 |
1-2. Metoda de măsurare
Vom măsor acest lucru folosind JMeter. JMeter este un instrument de măsurare a sarcinii care rulează în Java. Instrumentul permite ca un număr mare de cereri să fie lansate în același timp. Am dori să creștem treptat numărul de cereri simultane folosind JMeter și să creștem sarcina până când procesarea nu mai poate fi gestionată.
Condițiile specifice includ.
- interval de solicitare: 5 sec.
- Numărul de cereri simultane: 10 cazuri. (Măsurătorile au crescut treptat cu 10 cazuri fiecare.)
- Măsurarea timpului: 60 de secunde.
Timpul de măsurare este de "60 de secunde", iar intervalul de solicitare este de "5 secunde", deci doriți să accesați sistemul de 12 ori (60÷5) în mod repetat.
1-3. rezultatul măsurătorii
În cele din urmă, mulți oameni sunt interesați de concluzia privind specificațiile pe care serverul le poate gestiona și cât de mult poate gestiona, așa că aș dori să prezint mai întâi concluzia.
| CPU: 2core memory: 1GB SSD: 50GB | Pot fi procesate până la 80 de cereri simultane |
|---|
Rezultatele acestei măsurători au arătat cele de mai sus. Rezultatele de mai sus sugerează că pot fi deduse următoarele. Încercați să folosiți acest criteriu atunci când alegeți specificațiile serverului.
| CPU: 1core memory: 512MB SSD: 25GB | Pot fi procesate până la 20 de cereri simultane. |
|---|---|
| CPU: 2core memory: 1GB SSD: 50GB | Pot fi procesate până la 80 de cereri simultane |
| CPU: 3core memory: 2GB SSD: 100GB | Pot fi procesate până la 200 de cereri simultane. |
S-a constatat că un sistem cu o dimensiune de aproximativ 20 de utilizatori ar funcționa fără probleme cu "CPU: 1 nucleu", "memorie: 512 MB" și "SSD: 25 GB".
2. Detalii privind rezultatele măsurătorilor
Am descris mai devreme rezultatele măsurătorilor, dar dacă vă interesează ce fel de rezultate am descris, vă rugăm să verificați și detaliile rezultatelor măsurătorilor care vor fi descrise în viitor.
2-1. Măsurătorile serverului WEB/AP (Apache, Tomcat)
Solicitarea a fost lansată într-un scenariu în care utilizatorul se conectează din ecranul de logare și, după conectare, este afișat ecranul cu lista. De altfel, ecranul este construit folosind cadrul Spring, inclusiv funcția de autentificare.
Măsurătorile au arătat următoarele rezultate.
- Pentru 10 cereri simultane⇒OK
- Pentru 20 de cereri simultane⇒OK
- Pentru 30 de cereri simultane⇒OK
- Pentru 40 de cereri simultane⇒OK
- Pentru 50 de cereri simultane⇒OK
- Pentru 60 de cereri simultane⇒OK
- Pentru 70 de cereri simultane⇒OK
- Pentru 80 de cereri simultane⇒OK
- Pentru 90 de cereri simultane⇒NG
A apărut o eroare la al 90-lea caz. Cauza a fost o eroare de conectare la Apache. Starea serverului în acest moment era următoarea.
- Utilizare CPU: 26%
- utilizarea memoriei: 100%
Lipsa totală de memorie a fost cauza blocajului.
Pentru cei puțin mai pasionați, configurația Apache Multi-Processing Module (MPM) este următoarea. MPM este explicat pur și simplu ca fiind o setare a cât de mult poate procesa Apache în paralel.
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 250
MaxConnectionsPerChild 0
</IfModule>
Setarea de interes este "250" pentru "MaxRequestWorkers". Aceasta este o setare pentru numărul maxim de cazuri pe care Apache le poate procesa în același timp. "250", astfel încât 250 de cazuri au putut fi procesate în paralel la maximum, dar, dacă ne uităm la utilizarea memoriei, s-a folosit aproximativ 8 MB de memorie pentru fiecare caz.
Java părea să folosească 320 MB de memorie (248 MB pentru heap și 72 MB pentru metaspace), iar Apache 640 MB de memorie (8 MB x 80 de procese) și, deși valoarea de setare MPM a lui Apache este "250", se pare că nu putea crea mai mult de "80" de procese.
Notă: Serverul are 1G de memorie, astfel încât memoria totală pentru Apache și Java este de 960MB, ceea ce este aproape de limita superioară.
Serverul AP (partea Java) funcționa bine, astfel încât gâtul de gâtul de la intrare era serverul WEB (Apache).
Când Apache și Tomcat sunt instalate și rulează, am constatat că, cu specificațiile "CPU: 2core, memorie: 1GB, SSD: 50GB", numărul de accesări simultane "80" este limita. (Se presupune că setările de memorie pentru Java sunt de 248M pentru heap și 72M pentru metaspace.)
2-2. considerație
De aici încolo, devine o chestiune de luat în considerare, dar cum memoria este gâtul de gâtul de la intrare, dacă memoria este modificată, numărul de procese care pot fi procesate concomitent va crește.
(Prezent. (memory1GB))
- memory: 1GB
- Numărul de fire Apache: 80 de cazuri.
- Consumul de memorie pe fir de execuție în Apache.: 8MB
- Consumul de memorie Apache: 640MB (80 de cazuri.×8MB)
- Consumul de memorie Tomcat: 320MB (248 de milioane de euro pentru HEAP., 72m pentru metaspațiu.)
- Consumul de memorie al Apache+Tomcat: 960MB
(după modificare (memory2GB))
- memory: 2GB
- Numărul de fire Apache: 200 de cazuri
- Consumul de memorie pe fir de execuție în Apache.: 8MB
- Consumul de memorie Apache: 1600MB (200 de cazuri×8MB)
- Consumul de memorie Tomcat: 320MB (248 de milioane de euro pentru HEAP., 72m pentru metaspațiu.)
- Consumul de memorie al Apache+Tomcat: 1920MB
Cu o memorie de 2 GB, ar putea fi posibilă procesarea simultană a 200 de cazuri. Dacă memoria este mărită la 3GB, se pare că se poate face mai multă procesare concomitentă, dar "MaxRequestWorkers (numărul maxim de cazuri care pot fi procesate concomitent)" din MPM Apache este "250", așa că va fi necesară o ajustare și aici dacă memoria va fi mărită în continuare. De asemenea, este posibil să fie necesară ajustarea memoriei Java. În schimb, dacă memoria este înjumătățită, ar fi după cum urmează.
(după modificare (memory512GB))
- memory: 512GB
- Numărul de fire Apache: 20 de cazuri
- Consumul de memorie pe fir de execuție în Apache.: 8MB
- Consumul de memorie Apache: 160MB (20 de cazuri×8MB)
- Consumul de memorie Tomcat: 320MB (248 de milioane de euro pentru HEAP., 72m pentru metaspațiu.)
- Consumul de memorie al Apache+Tomcat: 480MB
3. rezumat
Sunt descrise rezultatele măsurării numărului maxim de cazuri pe care serverele WEB/AP (Apache și Tomcat) le pot procesa în același timp. S-a constatat că un sistem cu o dimensiune de aproximativ 20 de utilizatori ar funcționa fără probleme cu "CPU: 1 nucleu", "memorie: 512 MB" și "SSD: 25 GB".
Studiul se bazează pe ipoteza că niciun alt software nu rulează la o performanță marginală. Se recomandă să se aleagă o specificație cu o oarecare marjă de manevră, deoarece este o valoare marginală.
Sperăm că explicația a fost utilă.