Olcsó load balancert mindenkinek

rly?

képen a link és még itt.

Egyébként meg vannak még dolgok. Ezen röhögök már 3 órája.

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... 

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

[új] - No rainbow, no sugar - [új]

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.

Szerkesztve: 2020. 09. 29., k - 08:57

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 :)

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 :-)

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.

"Ö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.

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.

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.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

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:

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 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? :-)

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...

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 :-)

Kliens oldalon meg kellene peccselni, hogy csakis a hármasra vagy a nullásra menjen! :-)

<ironia on> legalabb konnyen olvashato a script logikaja ;) marmint az a keveske.... <ironia off>

reminder:

 

Pécsi Tudományegyetem Neptun Breach?

https://hup.hu/node/170346

 

amúgy ha talál vki bármi hibát, azt illik bejelenteni a megfelelő helyre :) megtettétek?