Fórumok
Sziasztok!
Végre érdekes szakmai téma került elő. Annak persze nem örülök, hogy emiatt túlórázni kell, de a nyomozós téma mindig érdekes.
Méricskélünk egy 2.4-es httpd-t mert nem hozza a rendszer az elvárt számokat. A cél 5-6000 egyidejű kérés kiszolgálása. Egyelőre nézzük a sima statikus fájl kiszolgálást - pl. 500k-s fájl - vagy a terheléselosztó üzemet mod_proxy-val.
A legtöbb helyen azt írják, hogy válts nginx-re, traefik-re ami persze egy lehetséges út, de most egyelőre az a mondás, hogy amíg nem tuti, hogy az Apache a szűk keresztmetszet, addig ne váltsunk.
Kíváncsi lennék a Ti tapasztalataitokra!
Hozzászólások
>A cél 5-6000 egyidejű kérés kiszolgálása
Mi az, hogy egyidejű, és mi az ami nem működik? Ha _tényleg_ egyszerre, egyetlen pillanatban jön be ennyi kérés, akkor egy részét eldobja még válaszadás előtt? Vagy timeoutra fut?
Ha belegondolsz eleve fából vaskarika, hogy _egyszerre_ jön 5-6000 kérés, mert a hálózati interfészen egymás után kell hogy jöjjenek :-).
Szerintem két kérdés is van ebben: Hány kapcsolat lehet aktív egyidejűen? Ugye HTTP2 esetén egyetlen kapcsolatban több HTTP lekérés is kiszolgálható, és hosszabb ideig is nyitva lehet a kapcsolat, mint egyetlen lekérés ideje.
Hány lekérést tud kiszolgálni a szerver egy adott idő alatt? Ebből számolható, hogy nagyjából mekkora átlagterhelés az, amit úgy tud kiszolgálni, hogy senki nem kap hibát.
JMeterből megy a kérés rampup nélkül (ügyfél ennyit határozott meg, hogy el kell bírni). Ha egy terhelő gép hálózatát kitömjük, akkor több gépről futtatjuk. A cél, hogy 0% hibával timeout-on belül jöjjön válasz.
Most azt látjuk, hogy olyan 2000 környékén már hibázgat, egy-két kérés timeout-ol. SSL nélkül jobban muzsikál valamivel ami nyilván logikus. Egy idő után van SYN queue meg accept queue hiba netstat -s alapján.
Melyik worker? Szerintem mindegyiknél lehet maxrequest/maxconnection stb. limiteket állítani, onnantól meg csak erőforrás kérdése.. ha valóban egyidőben esnek be a kérések, és közben mást is csinál a szerver, tcp szinten is lehet/kellhet tuningolni, pl. fin timeout, local port range, stb.
Próbáltuk mindkettővel, Prefork lényegesen lassabb.
Az jo mert 3 van ;). Eventet hasznaljatok.
Szia,
Szerintem is zsakutca az apache (es lehet a linux is), bar ebbol a leirasbol nem derul ki mi lesz majd a vegso feladata es milyen hw-en, de egy tipp, mi amikor reszeljuk a rendszerunket azt ugyanazon HW cfg-n csinaljuk es monitorozzuk, hogy a rendszer mennyi Gbps-t kepes kitolni per cpu% (pl.: ha ez az ertek 2 akkor 100% cpu usage mellet elmeletileg 200Gbps-t tudhat, persze ez nem mindig linearisa alakul, de egy jo alap), termeszetesen ehhez szukseges, hogy ugyanugy tudd reprodukalni a terhelest (itt nekem szerencsem van, mert csak raengedem a usereket es hajra:) ).
Legyen itt egy "tapasztalat" is, amennyiben static fileokat akarsz kiszolgani es kell https is, akkor kezdetnek linux helyett fbsd es nginx,sendfile(),ktls, ha meg akarsz rajta faszazni akkor cx6/7 nic, amivel tudsz tls offloadot.
Köszi! Szerintem ha megpendítem a freebsd átállást, itt páran leesnek a székről :)
Mivel egy spring/angular webapp kiszolgálása a cél, statikus kiszolgálás és proxy is kell, de a tényleges kiszolgálást hátra lehet tolni a terheléselosztó mögé, csak a https végződtetés mindenképpen a terheléselosztón van. Kérdés van-e érdemi különbség, ha az LB csak proxyzza a statikus tartalmat, vagy maga szolgálja ki.
Miért van a https terminalasa az LB-n mindenkeppen?
Akkor mondjuk úgy, hogy ha nem muszáj akkor ezen nem változtatnék.
Ez attól is függ, hogy milyen környezetben.
Szerintem mérjétek meg, és hasonlítsátok össze mással is.
Lehet egyébként paraméterezni, próbáljátok meg finomhangolni, stb... Attól is függ, hogy mennyit engedtek, mennyi idő után dobja el a kérést, stb...
5-6000 kérés az reális? Milyen alkalmazás, felhasználók kattintgatnak? Egy hatalmas alkalmazás esetén is lehet, hogy a ténylegesen egyidejű request szám mondjuk 20 db (csak a hasamra ütöttem) Közben lehet, hogy 5000-en használják egyszerre.
Erre nincs ráhatásom, az az ukász, hogy 5000 párhuzamos kérést vigyen el. Ezért érdekelne, hogy látott-e már valaki olyan Apache-t ami erre képes volt és ha igen, milyen erőforrás felhasználás mellett?
most én igazából tőled olyanokat várnék, hogy a jelenlegi vas egy x fizikai processzoros 1-2-4 socket, x core y thread
z GB ram, NVME háttértárral.
500 connect esetén így alakul a terhelés
1000 connect esetén amúgy
2000-nél már kezdenek gondok lenni, akkor emígy
arról elképzelésem nincsen, hogy az SSL lib-ben használt titkosítást éppen tudja-e hw offload-olni a CPU...
Ezt tudom, de ezért is kezdtem úgy a topicot, hogy tapasztalatokra vagyok elsősorban kíváncsi, hogy egyáltalán reálisan elérhető-e a cél?
Virtuális gép, 16G ram 4 vcpu, diszkről nincs infóm.
Igen, reálisan elvárható.
500 párhuzamos gépen fut majd, felhőben 100Gbit/s-os hálózaton, vagy egy pc-n a főnök irodájában az íróasztal mellett, a leselejtezett desktop gépén, ami ki lett nevezve egy szervernek? Most szándékosan írtam a két végletet. Tehát így értelmetlen a kérdés, mert nincs szofveres korlát.
Próbájátok ki, hogy ahol mennie kell, vagy hasonló környezetben mit teljesít (olyan helyen, ami alapján már tudtok becsülni), jó-e nektek, és hasonlítsátok össze egyéb más megoldásokkal is, pl nginx, vagy más. Ha van bármilyen mérésetek, akkor meg lehet még nézni a beállításokat, hogy lehetne tunningolni. A végén látni fogjátok, hogy mit kellene változtatni, akár konfigot, akár környezetet, és milyen irányba kellene menni.
De amúgy nekem gyanús ez a követelmény, mi az, aminek 5000 párhuzamos request-et kell tudnia? Tehát ezt a kérdést is tedd fel. Pl egy olyan alkalmazásban, amit felhasználók hajtanak meg, nem biztos, hogy van 5000 párhuzamos kérés. Szokásos hiba szokott lenni, hogy húúú, 5000 felhasználó volt bejelentkezve, akkor 5000 párhuzamos kérést kell tudni. Nem, mert nem egyszerre kattintanak, és nézik a képernyőt. (ez csak egy példa)
Szerk: egyébként sok minden van, pl kiosztható erőforrások, vagy a sok thread egyszerre nagyon sok memóriát tud foglalni, mert rengeteg adat van tárolva egy thread-ről. Nem véletlen kezdték el használni java alatt is a virtual thread-eket, pont az ilyen párhuzamos kérések feldolgozása miatt. De persze ettől még lehet egy alkalmazást úgy skálázni egy környezetben, hogy tudja az 5000 párhuzamos kérést.
Szarul megírt :D
Fedora 40, Thinkpad x280
ezt ismered?
http://www.kegel.com/c10k.html
igazabol a problema gyokere a select() illetve annak korlatai. vannak alternativai (pl. epoll, kqueue), anno ebben volt a bsd es az nginx jobb mert elobb implementaltak, de ma mar a linux/apache is tudja ugyanazt, csak jol kell bekonfolni. vszinu nem eleg az apacsot, hanem a kernelt (sysctl) is kell allitgatni ekkora terheleshez.
Nem ismertem, megnézem köszi!
Az 5-6000 egyidejü kérés önmagában nagyon felületes és nehezen értelmezhető elvárás. Az Apache prefork/worker modulja kb 25 évvel ezelőtti szemléletet követ (nagyon pongyolán: teljesen szinkron kliens kezelés, külön process vagy külön thread / connection).
Apache2 mellett az irány mindenképpen az mpm_event modul lesz. Ez valahol a worker modul és egy modern, teljesen aszinkron webszerver között van félúton.
Ez utóbbi már használ select/kqueue/epoll -t (megfelelőt a megfelelő rendszeren), de csak a connection kezelés async, a request-ek feldolgozása és kiszolgálása nem. Ez gyakorlatban abban fog segíteni, hogy nem lesz 5000 thread/process, illetve keep-alive mellett sem fejeli le a medence alját az Apache :)
Szóval a "cél 5-6000 egyidejű kérés kiszolgálása" értelmezésétől függően ez lehet egy röhögve megoldja vs. egy modernebb webszerver mellett is vértizzadós dolog :) Ha a kérdés felmerült, akkor mindenképp az utóbbi :)
// Happy debugging, suckers
#define true (rand() > 10)
Tehát akkor ha jól értem mivel a connection kezelés async akkor ha proxyként üzemeltetem - tényleges request feldolgozás nélkül - akkor röhögve bírnia kell?
függően, hogy mi van a túloldalon :) Konkrétumok, mérések és pontos adatok nélkül ennek a beszélgetésnek érdemben valahol itt van vége, bármi más csak találgatás és tippelgetés
// Happy debugging, suckers
#define true (rand() > 10)