Mekkora szerver(park) kell, hogy kiszolgáljon egyszerre egymillió lekérést?
[Nem tudom miért kellett lepontozni az első hozzászólót...]
Ez csak egy elméleti kérdés; onnan is elindulhatunk, hogy a legalapabb szerver mekkora forgalmat tud kezelni.
Ha valaki ért hozzá, hozzászólhatna.
"Nem tudom miért kellett lepontozni az első hozzászólót..."
Mert ezen az oldalon ez így megy. Ha valaki nem olyat ír, amit mások szeretnének hallani (olvasni), pláne, ha az nem valami überhagzatos véleményt tükröz, akkor gondolkodás nélkül lepontozzák. De nem csodálkozok. Eleve még az emberiség távol áll attól, hogy civilizáltnak lehessen nevezni, ezt még megfejeli az a tény, hogy a hazai oktatási rendszer ontja magából a tudatlan selejteket, így miért is lepődünk meg azon, hogy gondolkodás nélkül, érzésből értékelnek szakmai válaszokat?
#3 "Ki mondta hogy volt EGYSZERRE egymillió lekérés? A kérdés arról szólt, hogy mekkora szerverpark kellene egymillió lekéréshez egyszerre."
Ugyanazt írtad, csak megcserélted a szórendet. Taps-taps...
"onnan is elindulhatunk, hogy a legalapabb szerver mekkora forgalmat tud kezelni."
Igazából szerver bármi lehet, ami képes a kiszolgáló(k)tól érkező kéréseket teljesíteni. Még egy mikrovezérlő is képes rá, ha fizikailag tud csatlakozni az ügyfelekkel. Írtam én webszervert egy Arduino alapú meteorológiai állomásra. (16 MHz-es proci, 2 kB RAM.) Igaz, egyszerre csak egyetlen kérést tudott teljesíteni, de ez megvolt 6 ezer forintból. Hasonló árkategóriában már lehet lapszámítógépeket (SBC) kapni, a Raspberry Pi Zero W például ötezer forintomba került, és ez már hétköznapi értelemben véve is számítógép, és bár nem teszteltem le, hogy mennyi kapcsolatot bír el párhuzamosan, de 4-5 meg se kottyan neki. Igaz, azon is múlik, hogy mi az, amit szolgáltatnia kell. Nem maguk a kapcsolatok "eszik" igazán az erőforrásokat, hanem az a tény, hogy minden egyes ügyfél csatlakozásakor valamilyen folyamatnak le kell futni. Leginkább azon múlik az egyidőben kiszolgálható felhasználók száma, hogy ezek a folyamatok mennyi erőforrást igényelnek. Szintén visszakanyarodok a Raspberry lapszámítógépekhez, a pár ével ezelőtti nagyobb modell, a 3 B+ üzemel nálam házi szerverként. Fájlszerverként (közös meghajtó) működik elsődlegesen, de pl. ez gyűjti be a meteorológiai állomásom adatait, amiket feldolgoz és raktároz (PHP, MySQL), illetve webfelületen házon belül elérhető, archívummal együtt. 5 párhuzamos csatlakozást a közös meghajtóra (ebből egy épp másol rá), meg 3 ügyfelet a webszerverre simán ki tudott szolgálni. De próbaként feltettem egy Drupalt, na, az egyetlen ügyféllel is már fennakadásokat produkált. Ezeket csak azétr írom le, hogy szemléltessem: szélsőséges mértékben függ az egyszerre kiszolgálható ügyfelek száma attól, hogy hogyan írták meg a rendszert. Ez akár két nagyságrendnyi különbséget is jelenthet.
A munkahelyemen a DHCP+DNS+NTP szerverek egy virtualizált egymagos 2,1 GHz-es procit kapott 1 GB RAM-mal, és az átlagos processzorterheltsége 10% alatti, memóriaigénye meg 130 MB. Üzemeltetek iskolai Moodle szervert is, az már izmosabb jószág, ott a stabil működéshez 6 GB RAM kellett, és 3 db. 2,1 GHz-es processzormag. Csúcsidőben akár egyszerre 100-nál több tanuló is használja.
Továbbá: nem mindegy, hogy egy felhasználó teljes ottani tevékenysége alatt fenn kell tartani számára az erőforrásokat, vagy minden szükséges adatot elküld az ügyfélnek, amit az valamikor majd visszaküld. (Kicsit szakmaibban: fenn kell-e tartani aktívan egy munkamenetet, vagy sem.)
Egyébként ha jól látom, az EESZT oldala JSP alapú, ami azért nem igazán az erőforráshatékonyságáról híres.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!