Téma
- #nginx beállítások
Létrehozva: 2024-09-26
Létrehozva: 2024-09-26 21:20
Az nginx egy nyílt forráskódú szoftver, amelyet gyakran használnak webszerverként vagy web proxy szerverként.
A megfelelő konfigurációval hatékonyan szolgálhat ki statikus tartalmakat.
Ebben a bejegyzésben néhány fontos konfigurációs beállítást szeretnék leírni.
Egy weboldal betöltésekor számos fájlt kapunk a webszervertől, mint például JavaScript, képek, HTML és CSS fájlok.
A gzip tömörítéssel jelentősen csökkenthetjük az átvitt adatok mennyiségét, ahelyett, hogy az eredeti fájlokat küldenénk.
Tehát, ha ezt alkalmazzuk:
- Csökken az adatmennyiség, így megtakarítható a sávszélesség.
- Megtakarítható a szerver erőforrás.
- A felhasználók számára gyorsabb betöltési sebességet biztosít.
Ugyanakkor, mivel a szervernek a válasz küldése előtt gzip tömörítést kell végrehajtania, megnövekedhet a CPU terhelése.
Fontos a tesztelés a bevezetés előtt, hogy meghatározzuk, mely fájltípusokat tömörítsük, milyen tömörítési szintet alkalmazzunk, és mekkora fájlokat tömörítsünk.
Íme néhány gzip-hez kapcsolódó beállítás:
* A `gzip_vary` utasítás biztosítja, hogy a kliens gzip támogatása esetén tömörített, támogatás hiányában pedig tömörítetlen verziót kapjon a tartalomból. (Jelzi, hogy a kliens kérés fejléce (Accept-Encoding) alapján különböző verziójú tartalom kerülhet kiszolgálásra.)
Az nginx a válaszokat pufferben tárolja, mielőtt elküldi a kliensnek.
Ha a kliens lassú, a szervernek várnia kell az adatok elküldésével. (Hálózati torlódás)
Ez folyamatos szerver terhelést jelent. A puffereléssel a kliens sebességétől függetlenül ideiglenesen tároljuk a válaszokat. Ennek előnyei:
- Optimalizált szerverterhelés
- Csökkentett hálózati torlódás
※ Túl nagy pufferméret esetén a valós idejű adatátvitel (pl. text streaming) késhet, ezért tesztelés szükséges. Különösen az AI-alapú szolgáltatások esetében fontos ellenőrizni ezt a beállítást, ha a szöveg streamelés nem működik megfelelően.
A worker folyamatok kezelik a kliensek kéréseit, és beállítható, hogy a CPU magonként hány worker futjon.
Az http protokollban általában kérés-kapcsolat-válasz-kapcsolatbezárás a menet, de a kapcsolatok újrahasznosításával (keep-alive) csökkenthetjük az erőforrás-felhasználást.
A két beállítást együtt említjük az alábbi okokból:
Ha a szervernek 4 magja van, akkor elméletileg 1024 * 4 = 4096 kapcsolatot tud kezelni.
(Az erőforrások és a forgalom függvényében ez az érték nem mindig pontos.)
Ha 4096 kliens csatlakozik egyszerre, és 65 másodpercig foglalják le a keep-alive kapcsolatokat,
akkor a 4097. felhasználó nem tud csatlakozni, ami késést okozhat.
Tehát, ha feltételezzük, hogy az automatikus skálázás biztosítja a stabil erőforrásokat, akkor az események során fellépő késések oka lehet a fenti beállítások.
A proxy puffer és más beállítások kérésenkénti URL alapján is konfigurálhatók.
* A keep-alive és néhány más beállítás a HTTP/szerver szinten van alkalmazva, így nem blokkonként konfigurálható.
server {
listen 80;
server_name example.com;
A fenti beállításokkal optimalizálhatjuk a webes teljesítményt. Több tesztesettel alaposan teszteljük a beállításokat, mielőtt élesben alkalmazzuk őket!
* A módosított nginx konfiguráció általában leállás nélkül alkalmazható, így meglehetősen biztonságos.
Hozzászólások0