Apache un Tomcat slodzes tests VPS vidē: veiktspējas ierobežojumi un rezultāti


Publikācijas datums:

Atjaunināts:


Tehniskie raksti > Apache un Tomcat slodzes tests VPS vidē: veiktspējas ierobežojumi un rezultāti

2026. gada statuss un droša lietošana

Galvenais: Apache un Tomcat sistēmā pirmais ierobežojums var būt slodzes ģenerators, Apache darbinieki, Tomcat savienotāja pavedieni, JVM kaudze vai atkritumu savākšana, lietojumprogrammas kods, datubāze vai pats VPS. Viens vienlaicīgo pieprasījumu skaitlis neraksturo jaudu bez latentuma, kļūdu un resursu mērījumiem.

Ko jūs uzzināsiet

  • Kas tika mērīts sākotnējā divu līmeņu VPS eksperimentā.
  • Kā starpniekservera un Tomcat savienotāja ierobežojumi mijiedarbojas ar lietojumprogrammas reakcijas laiku.
  • Ko reģistrēt mūsdienīgā testā: procentiles, caurlaidspēju, kļūmes, CPU un atmiņas lietojumu, GC, pavedienus un pakārtoto sistēmu piesātinājumu.

Kam tas paredzēts: Java tīmekļa izstrādes komandām, kuras vēlas izveidot nelielu, uz mērījumiem balstītu jaudas pārbaudi.

2026. gada konteksts: tālāk norādītie rezultāti attiecas uz autora sākotnējo testu, un tie netika reproducēti šim redakcionālajam atjauninājumam. Uztveriet tos kā gadījuma izpēti, nevis pārbaudītu pašreizējo veiktspēju vai VPS iegādes ieteikumu.

Drošības piezīme. Sākotnējā rakstā esošās komandas un konfigurācijas piemēri nav atkārtoti izpildīti pašreizējā ražošanas vidē. Pirms to lietošanas pārbaudiet atbalstītās versijas, dublējumus, piekļuves vadīklas un atcelšanas darbības atsevišķā testa vidē.

Galvenie oficiālie avoti

Pārskats

Šajā vēsturiskajā eksperimentā tika palielināts vienlaicīgo pieprasījumu skaits Apache un Tomcat sistēmai vienā VPS, lai novērotu pirmo kļūmes punktu. Rezultāti attiecas tikai uz norādīto vidi un testa scenāriju, nevis uz visām Apache un Tomcat instalācijām.

Šajā lapā aplūkota divu slāņu Apache un Tomcat sistēma. Atsevišķā rakstā aprakstīts tests tikai ar Apache.

Apache HTTP servera slodzes tests nelielā VPS: metode un rezultāti

Satura rādītājs

  1. Mērījumi
  2. Detalizēta informācija par mērījumu rezultātiem
  3. Kopsavilkums

1. Mērījumi

1-1. Mērījumu vide

Testa vide bija šāda.

■ VPS informācija

CPU2 kodoli
Atmiņa1 GB
SSD50GB

■ Servera programmatūra

OSCentOS 7.4 64bit
Tīmekļa serverisApache HTTP Server 2.4.41
AP serverisApache Tomcat 9.0.27
DB serverisPostgreSQL 10.2
JavaOpenJDK 11

1-2. Mērīšanas metode

Slodze tika ģenerēta ar Java vidē darbināmo rīku JMeter. Vienlaicīgo pieprasījumu skaits tika pakāpeniski palielināts, līdz sistēma tos vairs nespēja sekmīgi apstrādāt.

Testa nosacījumi bija šādi.

  • Pieprasījumu intervāls: 5 sekundes.
  • Sākotnējais vienlaicīgo pieprasījumu skaits: 10; katrā nākamajā mērījumā tas palielināts par 10.
  • Mērījuma ilgums: 60 sekundes.

Tā kā mērījums ilga 60 sekundes un intervāls bija 5 sekundes, katra virtuālā lietotāja darbība atkārtojās 12 reizes (60÷5).

1-3. Mērījumu rezultāti

Vispirms apkopoti toreizējā testa rezultāti pēc izmantotās VPS konfigurācijas.

CPU: 2core
memory: 1GB
SSD: 50GB
Vienlaikus var apstrādāt līdz 80 pieprasījumiem

Šie skaitļi ir konkrētā testa novērojumi. Tie nav garantēta jauda un nav tieši pārvēršami reālu lietotāju skaitā.

CPU: 1core
memory: 512MB
SSD: 25GB
Vienlaikus var apstrādāt līdz 20 pieprasījumiem.
CPU: 2core
memory: 1GB
SSD: 50GB
Vienlaikus var apstrādāt līdz 80 pieprasījumiem
CPU: 3core
memory: 2GB
SSD: 100GB
Vienlaikus var apstrādāt līdz 200 pieprasījumiem.

Vēsturiskajā aprēķinā konfigurācijai "CPU: 1 kodols", "atmiņa: 512 MB" un "SSD: 25 GB" tika prognozēti aptuveni 20 vienlaicīgi pieprasījumi. Tas neapliecina, ka šāda sistēma bez problēmām apkalpos 20 reālus lietotājus.

2. Detalizēta informācija par mērījumu rezultātiem

Tālāk parādīti detalizētie novērojumi, uz kuriem balstīts iepriekšējais kopsavilkums.

2-1. WEB/AP servera (Apache, Tomcat) mērījumi

Scenārijā lietotājs pieteicās sistēmā un pēc autentifikācijas atvēra saraksta skatu. Lietojumprogramma, ieskaitot autentifikāciju, bija veidota ar Spring.

Testā tika novēroti šādi rezultāti.

  • 10 vienlaicīgi pieprasījumi ⇒ OK
  • 20 vienlaicīgi pieprasījumi ⇒ OK
  • 30 vienlaicīgi pieprasījumi ⇒ OK
  • 40 vienlaicīgi pieprasījumi ⇒ OK
  • 50 vienlaicīgi pieprasījumi ⇒ OK
  • 60 vienlaicīgi pieprasījumi ⇒ OK
  • 70 vienlaicīgi pieprasījumi ⇒ OK
  • 80 vienlaicīgi pieprasījumi ⇒ OK
  • 90 vienlaicīgi pieprasījumi ⇒ kļūme

Pie 90 vienlaicīgiem pieprasījumiem radās Apache savienojuma kļūda. Servera stāvoklis tajā brīdī bija šāds.

  • CPU noslodze: 26%
  • Atmiņas izmantojums: 100%

Šajā testā pirmā novērotā vājā vieta bija atmiņas trūkums.

Apache Multi-Processing Module (MPM) nosaka procesu vai pavedienu pārvaldības modeli un vienlaicīgās apstrādes ierobežojumus. Izmantotā konfigurācija bija šāda.

<IfModule mpm_prefork_module>
    StartServers             5
    MinSpareServers          5
    MaxSpareServers         10
    MaxRequestWorkers      250
    MaxConnectionsPerChild   0
</IfModule>

MaxRequestWorkers vērtība bija "250". Tā ir konfigurācijas augšējā robeža vienlaicīgi apkalpotiem pieprasījumiem, nevis garantija, ka pietiks CPU, atmiņas vai citu resursu visu 250 pieprasījumu apstrādei. Šajā novērojumā vienam Apache procesam tika aptuveni attiecināti 8 MB atmiņas.

Java izmantoja aptuveni 320 MB atmiņas (248 MB JVM kaudzei un 72 MB metaspace), bet Apache — aptuveni 640 MB (8 MB × 80 procesi). Kopējais aprēķins bija 960 MB, tāpēc 1 GB serveris bija gandrīz sasniedzis atmiņas robežu, lai gan MaxRequestWorkers bija iestatīts uz "250".

Šajā konkrētajā testā savienojuma kļūme tika novērota Apache pusē, bet atmiņas patēriņā piedalījās gan Apache, gan Java process.

Konfigurācijā "CPU: 2 kodoli, atmiņa: 1 GB, SSD: 50 GB" pēdējais sekmīgais mērījums bija 80 vienlaicīgi pieprasījumi. Java atmiņas iestatījumi bija 248 MB JVM kaudzei un 72 MB metaspace.

2-2. Rezultātu interpretācija

Tā kā šajā testā atmiņa bija pirmā vājā vieta, sākotnējā rakstā tika veikts vienkāršots lineārs aprēķins dažādiem atmiņas apjomiem. Tas ir aptuvens pieņēmums: reālā slodzē atmiņas patēriņš nav obligāti nemainīgs, un ierobežojumu var sasniegt CPU, atkritumu savākšana, datubāze vai cita komponente.

Pašreizējā konfigurācija (1 GB atmiņas)

  • Atmiņa: 1 GB
  • Apache procesi: 80
  • Aptuvenais atmiņas patēriņš vienam Apache procesam: 8 MB
  • Apache aprēķinātais atmiņas patēriņš: 640 MB (80 × 8 MB)
  • Tomcat atmiņas patēriņš: 320 MB (248 MB JVM kaudzei un 72 MB metaspace)
  • Apache un Tomcat kopējais atmiņas patēriņš: 960 MB

Vienkāršotais aprēķins 2 GB atmiņai

  • Atmiņa: 2 GB
  • Apache procesi: 200
  • Aptuvenais atmiņas patēriņš vienam Apache procesam: 8 MB
  • Apache aprēķinātais atmiņas patēriņš: 1600 MB (200 × 8 MB)
  • Tomcat atmiņas patēriņš: 320 MB (248 MB JVM kaudzei un 72 MB metaspace)
  • Apache un Tomcat kopējais atmiņas patēriņš: 1920 MB

Lineārais aprēķins paredzētu aptuveni 200 procesus ar 2 GB atmiņas, taču tas nav izmērīts rezultāts. Pirms maināt MaxRequestWorkers vai JVM atmiņas iestatījumus, pārbaudiet faktisko latentumu, kļūdas, atkritumu savākšanu un visu servera resursu patēriņu.

Vienkāršotais aprēķins 512 MB atmiņai

  • Atmiņa: 512 MB
  • Apache procesi: 20
  • Aptuvenais atmiņas patēriņš vienam Apache procesam: 8 MB
  • Apache aprēķinātais atmiņas patēriņš: 160 MB (20 × 8 MB)
  • Tomcat atmiņas patēriņš: 320 MB (248 MB JVM kaudzei un 72 MB metaspace)
  • Apache un Tomcat kopējais atmiņas patēriņš: 480 MB

3. Kopsavilkums

Vēsturiskajā testā Apache un Tomcat sistēma ar 1 GB atmiņas sekmīgi apstrādāja līdz 80 vienlaicīgiem testa scenārija pieprasījumiem, bet pie 90 pieprasījumiem radās kļūme un atmiņas izmantojums sasniedza 100%.

Šo robežu nevar pārvērst lietotāju skaitā vai pārnest uz citu konfigurāciju. Jaudas plānošanai izveidojiet reprezentatīvu scenāriju, nosakiet latentuma un kļūdu sliekšņus un testēšanas laikā reģistrējiet Apache, Tomcat, JVM, datubāzes un operētājsistēmas metriku.