- tomsolo blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
azon tul, hogy kicsit alternativ megoldas, meg nem is egyenletes :(
kivancsi vagyok, h a terhelesi grafikonokbol latszik-e, h a szerverek 0.16, 0.33, 0.33, 0.16 aranyban kapjak a loadot...
- A hozzászóláshoz be kell jelentkezni
Na ja... Mondjuk ezért is "illene" alapvető matematikai ismeretek és logikus gondolkodás hiányában elkerülni a szoftverfejlesztésnek még a környékét is...
- A hozzászóláshoz be kell jelentkezni
lehet a web2, és web3 szerver annyival erősebb, hogy pont kiegyenlítik ezt a különbséget ;)
- A hozzászóláshoz be kell jelentkezni
Ez a megoldás egy dolgot tud kicsit megoldani abból a sokból, amit egy load balancerre szoktak rábízni. A semminél több, de rengeteg gond lehet vele.
- A hozzászóláshoz be kell jelentkezni
ez semmit nem tud megoldani abból amit egy load balancerre bízni szoktak
eleve a fenti kód miatt a 3-as szerver a legjobb, ráadásul mivel nem a terhelés a függvényében irányít át hanem kliens random , dönti el éppen hova menjen ezért az egyik lekérés működni fog a másik meg nem
No rainbow, no sugar
- A hozzászóláshoz be kell jelentkezni
Egy kicsit megoldja azt hogy a requestek elszóródjanak több node között, nade lenne itt egy halom kérdés még ezen kívül :)
Egyébként ez egy forward link targetjét módosítja, vagyis ha elugrunk a 4-es node-hoz onnantól kezdve fixen azt kattogtatjuk. Tehát a belépési pontjál megjön a döntés hogy hova megyünk és utána maradunk is ott.
- A hozzászóláshoz be kell jelentkezni
Biztos, hogy a hármas? :-P
- A hozzászóláshoz be kell jelentkezni
ráadásul mivel nem a terhelés a függvényében irányít át
Teljesen mindegy, egy sörben fogadok, hogy DB szerver pl. úgyis csak egy van :)
- A hozzászóláshoz be kell jelentkezni
Úriember biztosra nem fogad ;)
- A hozzászóláshoz be kell jelentkezni
Ezt még ZX Spectrum BASICben is úgy volt szokás, hogy INT(RND*4) :D
- A hozzászóláshoz be kell jelentkezni
Ez The Daily WTF-re méltó találat.
- A hozzászóláshoz be kell jelentkezni
Tökmindegy egyébként mert a backend/sql része skálázhatatlan. Legalábbis amíg én neptunok közelében voltam, nem létezett olyan tárgyfelvételi időszak ami ne arról szólt volna hogy szanaszét szakad az egész.
(és volt vagy 6 node-os balancing)
Vagy ha azt nézzük hogy a neptun első verziója egy remote desktoppal megközelíthető windows alkalmazás volt, akkor azt is mondhatjuk, hogy rengeteget fejlődött :)
- A hozzászóláshoz be kell jelentkezni
Igen, mi még azzal szívtunk. Borzalmas, hogy mennyire szar.
Szeretek azon elgondolkodni, hogy egy problémakör valójában mennyi adatról szólna, ha lehántanánk róla a "felesleges" rétegeket?
Van az egyetemnek kb 10000 hallgatója, és egy hallgató jelentkezik mondjuk átlagban 10 tárgyra (Hallgatónként 400bájt bőven elég tárolni). Van mondjuk 1000 tárgy, és mindegyikhez tartozik némi metaadat, hogy mikor vannak órák, hányan jelentkezhetnek maximum, stb. A hallgatóknak is van némi metaadata, hogy milyen képzésen van, ebből következik, hogy mit kötelező és mit tilos felvennie. Mondjuk hallgatónként 1kB
Számoljunk:
* Hallgató metaadat: 10000*1kB = 10MB
* Jelentkezések 10000*400B=4MB
* Tárgy metaadat 1000*5kB=5MB
Összesen tehát kb 20 MB adatot kell kezelni. Egy mai vason ha egyetlen szálon tranzakciónként hajtanánk végre minden műveletet, akkor is az egész nap összes tranzakciója (kb 10000*10=100.000 tranzakció) lefutna néhány másodperc alatt ha tisztességesen meg lenne csinálva :-).
Ezt a problémát sikerült akkorára fújni ügyes szoftveres trükkökkel, hogy a világ összes vasa ne legyen elég alá - mivel nem is skálázódik :-)
- A hozzászóláshoz be kell jelentkezni
Szerintem amit felvázoltál, az manapság minden rendszerre igaz bizonyos mértékben, ami bármiféle adatot kezel. Már nem divat "bitszintű" :) adattároláson gondolkodni, mert könnyebb és "trendibb" felhasználni valami kész - és sokszor overkill - megoldást.
- A hozzászóláshoz be kell jelentkezni
"Összesen tehát kb 20 MB adatot kell kezelni." - szemeszterenként növekszik x mennyiséggel, archív adatokkal, audit és egyéb naplózási információkkal, estébé, estébé, estébé...
Az, hogy skálázódik-e, az jó kérdés - mondjuk ha a frontendben ilyen gányláda "megoldás" van, akkor persze esélyes, hogy a backend/DB réteg is hasonlóan sz@r, ebben igazad van.
- A hozzászóláshoz be kell jelentkezni
Persze, nyilván van egy rakás egyéb amit tárolni kell, de amit skálázhatóan meg kell oldani arra az 1 napra, az 20 MB felülről. Ennyi év fejlesztés után akár külön memória adatbázisban is lehetne, ami csak tranzakció logot köpdös magából storage-re, hogy mennél gyorsabbak legyenek a tranzakciók.
- A hozzászóláshoz be kell jelentkezni
Az in-memory DB akkor "jó", ha van mögötte olyan szintű replikáció(!), ami az adott node-ból kirángatott tápfeszültség esetén is megőrzi a kommitált módosításokat.
- A hozzászóláshoz be kell jelentkezni
Mondom, hogy kiköpi a tranzakció logot.
- A hozzászóláshoz be kell jelentkezni
Azaz diszkre írás van, legalább redo szinten...
- A hozzászóláshoz be kell jelentkezni
Egy file-t kell irni (logot), szekvencialisan. Nem tunik megoldhatatlan feladatnak ez sem a mai hardware-ek mellett. (de a 10 eves desktop gepem is megugrana szerintem a feladatot).
A fenti felvetes szerint van 10000 hallgato, atlagban mind 10 targyra jelentkezik. Egy jelentkezesben legyen idobelyeg (8 byte), hogy mikor mire nyomott, hallgato ID (legyen 4 byte, de lehet 8, mind1), tantargy ID, kurzus ID, orarendi idopont, hogy mi tortent (jelentkezes/torles), ha 1kbyte-ot tippelek ra, az bo felso becsles. Ez 100MB log, nem ennek a kiirasa lesz a szuk keresztmetszet. Ha toketlenkednek, es fel-le jelentkezik valaki, kicsit megnoveli, de meg mindig vicc.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
A BME-n egy időben rendszeresen adtak ki post-mortemeket a tárgy- és vizsgajelentkezések után, amiben egyrészt magyarázatot adtak az esetleges fennakadásokra, másrészt adtak statisztikákat a tranzakciók számáról. Az archive.org-on fellelhetőek ezek a dokumentumok eddig. Érdemes elolvasni, hogy milyen problémákba ütköztek, milyen megoldásokat találtak ezekre, hogyan finomhangolták a rendszert. Néhány példa:
- A hozzászóláshoz be kell jelentkezni
Köszi a linkeket!
Nem lettem volna annak a helyében, akinek ezeket a jelentéseket kellett írni...
Érdekes, hogy ekkor már legalább tíz éves volt a Neptun, mert mikor én jártam a BME-re már akkor is ez volt... És akkor is folyton összeomlott tárgyfelvételkor :-)
És valóban volt amikor úgy működött, hogy a belépésnél kizárt, ott kellett újraindítgatni, de ha egyszer bekerültünk, akkor egész normálisan működött. Régi szép idők...
- A hozzászóláshoz be kell jelentkezni
A harmadik linkben van egy ilyen:
"(A Neptun fejlesztője itt egy praktikus várakoztató ciklust épített be a rendszerbe, amely a
hallgató beavatkozása, gombnyomogatása nélkül, automatikusan belépteti a hallgatót, amint szabad
hely adódik a webszerveren.)"
Ebben az a jó, hogy elsőre nem lép be. Mit csinál a user? Elmegy KV-zni, valamit elintéz, dumál, stb. Aztán belép a rendszerbe a gép, foglalja a drága jó "aktív Netpun felhasználó" helyet, de a user nincs is a gépnél. Így legalább nem csinál terhelést, és érdekes módon a terheléselosztó a statisztikák szerint több usert is elbír egyszerre. Ujjé! A következő tárgyfelvételnél több usert lehet egyszerre beengedni! :-)
Miért nem lehetett erre terheléses tesztet csinálni? Mert nem volt infrastruktúra, amin le tudták volna futtatni a tesztet? :-)
- A hozzászóláshoz be kell jelentkezni
Megoldásaim nekem is vannak/lennének, de a fejlesztők nagyon sokszor nem látnak messzebb az aktuális fejlesztőeszköztől, nem látják át a környezetet, a tényleges terheléseket, nem arra méreteznek (nem méreteznek), hanem a funkció jól-rosszul történő megvalósítását tekintik célnak. Aztán ha lassú, köhög, akkor az a mondásuk, hogy "még erőforrást neki"...
Amikor egy fejlesztőnek teljesen normális megoldás az, hogy pl. egy alkalmazásszerver a mögötte lévő Oracle-ből veszi a statikus tartalmakat is, ráadásul úgy, hogy azok Oracle szinten external blobként vannak a fájlrendszerben tárolva (mert igény volt, hogy azokat az alkalmazás újrabuildelése/redeploy nélkül is lehessen cserélni), vagy épp tele van a kódja olyasmivel, hogy "select * from" - és az megy be egy előre definiált tömbszerű adatszerkezetbe, amiben majd keresgél... Nos amikor ilyen "fejlesztők" jönnek szembe", akkor kezdem megérteni, hogy miért oylanok az alkalmazások, amilyenek...
- A hozzászóláshoz be kell jelentkezni
Igen, pont ezek a problémák.
A minimális szükséges adat becslését nem azért mondtam, hogy akárcsak én is így oldanám meg a problémát, hanem csak egy módszer vagy gondolkodásmód érzékeltetésére. Ha egy ilyen analízisből kijön, hogy egy feladat lehetetlen, akkor az tényleg lehetetlen. Ha az jön ki, hogy nehezen fér be, akkor az tényleg nehéz lesz... Ha viszont kijön, hogy van egy-két nagyságrednyi lauf, az egész sima ügy, attól még a valóságban lehet nehéz a probléma :-)
- A hozzászóláshoz be kell jelentkezni
Kliens oldalon meg kellene peccselni, hogy csakis a hármasra vagy a nullásra menjen! :-)
- A hozzászóláshoz be kell jelentkezni
Vagy eleve a megfelelő frontend szervert teszed bookmarkba :)
- A hozzászóláshoz be kell jelentkezni
Avi Networks csodbe is megy, hogy ok erre nem gondoltak :D
- A hozzászóláshoz be kell jelentkezni
Csóró Facebook egészen a hálókártya driver-ig viszi le a loadbalancert (Katran) közben meg offloadolható a kliens oldalra is
- A hozzászóláshoz be kell jelentkezni
<ironia on> legalabb konnyen olvashato a script logikaja ;) marmint az a keveske.... <ironia off>
- A hozzászóláshoz be kell jelentkezni
reminder:
Pécsi Tudományegyetem Neptun Breach?
amúgy ha talál vki bármi hibát, azt illik bejelenteni a megfelelő helyre :) megtettétek?
- A hozzászóláshoz be kell jelentkezni