Lekönyökölt a Netflix streaming rendszere a Jake Paul vs. Mike Tyson mérkőzés alatt

Internet, Közösségi média

Aki fent maradt éjjel megnézni a Jake Paul vs. Mike Tyson eseményt a Netflixen, az valószínűleg szentségelt jó párszor, mert a minden idők egyik legnagyobb élő streaming közvetítéseként beharangozott műsort számtalanszor szakították meg technikai problémák. Gyakori volt a disconnect, a pufferelés. A boxrajongók egy része feldühödött, és elkezdte lemondani a Netflix előfizetését. Elszabadultak a mémgyárak is, a Twitter tele van a haragos / szarkasztikus kommentekkel.

Érdekes a dolog, mert a mérkőzést hónapokkal ezelőtt kezdték előkészíteni, promózni. Sőt, Tyson betegsége miatt hónapokkal el is halasztották, vagyis a Netflixnek lett volna ideje megfelelően felkészülni technikailag.

Azért meglepő ez, mert itt a HUP-on (saját bevallásuk szerint) számos szakértő van, aki kisujjból kiráz egy olyan rendszert, ami on-demand skálázódik az igényeknek megfelelően. De akkor mi lehetett a probléma? A FreeBSD? Nem volt elég pénz? Nem volt elég idő? Inkompetencia? Írd le a hozzászólásokban!

( szipka | 2024. 11. 16., szo – 11:56 )

Szerkesztve: 2024. 11. 16., szo – 11:57

Lehet hogy sok szakerto van aki sajat bevallasa szerint kisujjból kiráz egy ilyen rendszert, de a szaktudas mar sokkal kevesebb van. Nem akarok megbantani senkit, egyszeruen limitalt a megszerezheto gyakorlat. Limitalt hogy hany ceg foglalkozik magyarorszagon ilyesmivel. Olyan nincs hogy on demand skalazodik a vegtelenbe es tovabb ... Es nem csak technikai okai lehetnek. Felhuzni exrta infrat csak ezert az egy esemeny miatt, meg ha nem is fizikai infra volt, lehet hogy egy manager kiszamolta azt mondta eddig es nem tovabb, es az eddig keves lett. Nem hiszem hogy a Netflix ne tudna barmilyen adott meretu infrat felhuzni es megfelelo SLA-vel uzemeltetni. Itt vagy a forgalom becsles volt helytelen vagy a penz nem volt eleg.

Dobrev Klárával, akarom mondani PopcornTime-al sikerült volna! Annál ugyebár a felépítéséből adódóan minél többen nézik annál masszívabb a hálózat. Persze lehet azzal kontrázni, hogy a PopcornTime nem is liveozásra lett kitalálva de talán nem nehéz belátni, hogy nem túl bonyolult live funkcióval kiegészíteni. Egyébként meg WebTorrent Ace Stream és Peer5. 

Aki nem az élet iskolájában tanulta az informatikát hanem egyetemen, volt hálózatos tárgya ahol hallhatott olyan dolgokról mint multicast. Pont erre való. Szóval arra kérdésre, hogy balfasz-e a Netflix? a válasz egyértelmű Igen! 

A valóság az, hogy nem személyeskedtem. Tudom, hogy egyeseknek van ezzel problémája itt, és azt, ha a hozzászólásukat kritika éri azt személyeskedésnek veszik, de az nem az. Nem a személyed miatt hülyeség amit írtál, hanem csak úgy, és nem a személyed alapján minősítettem a helyzetet annak (aka "hülye vagy és képtelen vagy megérteni") hogy bemutatod mennyire nem érted miről van szó. 
Szóval milyen tükör az amikor az írásodat ért kritikát azzal hárítod, hogy a másik nem ért hozzá? Elmondom: nincs valódi érved. 
Az ide rakott írásod szakmai értékelése:  "pfff. kínos"

Például erre lenne a 224.0.1.0 - 224.0.1.255 tartomány. Illetve IPv6 -nál a ff00::/8  multicast tartomány ami sokkal inkább ajánlott multicast-ra. Ha nem sikerülne minden internetszolgáltatóval megállapodni a multicast közvetítésről akkor a legközelebbi alkalomra erős motiváció lenne az, hogy a multicast megállapodást kötött internetszolgáltatók ügyfelei jobb minőségű, nagyobb sávszélességű streamet kapnak, még a multicastból kimaradó ügyfelek be kell érjék a gyengébb unicast streammel. Továbbá a multicastban résztvevő szolgáltatók a saját hálózatukat is kímélik. 

Amennyiben a Netflix meg tud állapodni néhány internetszolgáltatóval, akkor ezeknek az ISP-knek a hálózatán belül működhetne a multicast. Ezek kellenek hozzá IPv4 multicastnál: IGMP, Internet Group Management Protocol. A végfelhasználói eszközök és a hálózati routerek közötti multicast-csoportok kezeléséhez.
PIM, Protocol Independent Multicast. Ez pedig a multicast forgalom hatékony útvonalainak kiépítéséhez.
Valamint multicast csoportok használata. Azaz Netflixnek dedikált multicast címeket kellene használni az élő események közvetítéséhez. Ezeket a címeket az ISP-ken belül kellene konfigurálni és fenntartani.

IPv6 viszont multicastra optimálisabb megoldás, amennyiben a szolgáltatók és a hálózatüzemeltetők szélesebb körben támogatnák. Sőt már ha regionális szinten sikerül megállapodni akkor is megvalósítható.
Ha a Netflix minden internetszolgáltatóval Észak-Amerikában megállapodást kötne, a multicast közvetítés IPv6-on már működhetne abban a régióban. Ez azért lehetséges, mert az IPv6 multicast alapvetően jobban támogatja az ilyen típusú adatforgalmat, és a multicast címek globális vagy regionális terjedését is jobban lehetne koordinálni az internetszolgáltatók között.

A Párizsi olimpián volt voltak már sávszélességproblémák egynéhány túl nagy érdeklődés középpontjában álló sporteseménynél. Ez a veteránok közötti box-meccs pedig eleve egy hálózati teszt is volt, amit szemben az olimpia eseményeivel szabadon időzíthetett a Netflix. Ha sikerül összehoznia legalább Észak-Amerikában, de akár több régióban is egy-egy multicast megállapodást, azzal mindenki nyert volna. az ISP-k is és a Netflix is aki először összehozta. Igény volna erre, ami már az olimpián is jól érzékelhető volt. Természetesen jó ideig maradna a hibrid megoldás, azaz multicast és a CDN együttes alkalmazása a nagy érdeklődést kiváltó (elsősorban) sporteseményekre, mivel a nézők otthoni eszközei nem mindenkinél támogatják a multicastot és ekkor hiába van Netflix és ISP között megállapodás. A jobb minőséget viszont a multicast nézők kapják, ami erős motiváció sportrajongóknál az eszközök rendszereinek, beállításainak frissítésére, illetve cseréjére. 
Továbbá kombinálható a szintén említett Peer-to-Peer streaming megoldással is, ami lehetővé teszi, hogy az ügyfelek megosszák a streamet egymással, csökkentve a hálózati terhelést. De ennek részletezése megint egy külön téma. 

Ja, mert a világ direkt linkeken keresztül működik :) Az, hogy technológiákat listázol, nem teszi szakmaivá a hozzászólást. Szerinted miért nem csinálja a Netflix? Oké, tegyük fel a sommás véleményed az, hogy "mindenki hülye rajtad kívül". Mégis az az érdekes kérdés nem merült fel, miért nem csinálja nagyjából senki? (vannak elszigetelt próbálkozások MVPN megoldásokka, kb ennyi) Csak úgy kérdem. Oszd meg kérlek végtelen bölcsességedet.

Koszi hogy kifejtetted, ez egy szep magas szintu elmeleti leiras, maga a topic egy diplomamunkanak is eleg lehetne.
A cel jo az eredmeny is kb jo lehet, de alabbi nehezsegek es kockazatokat rejti a "melos" velemenyem szerint,

- Az eyeball ISP nem minden esetben erdekelt abban, hogy veled barmilyen szinten is egyutt mukodjon

- Ott lehet ezzel hatekonyan eredmeny elerni, ahol a legtobb a usered van es az altalaban egy Incumbent ISP, ami nagy, lassu plusz lasd az elso pontot

- A multicast-hoz hasznalt protocol-ok mukodeset rfc-k hatarozzak meg, de sajnos lehetnek es vannak is eszkoz-eszkoz kozotti elteresek/problemak,
ha ebbol gond van az nem csak a te szolgaltatasodat/usereidet erinteheti, hanem mondjuk beboritja az ISP-t kompletten itt-ott.
Ezert ez nagyon nagy risk egy ISP reszerol is, amit nem akarnak bevallalni.

- Az otthoni eszkozoknel is okozhat ez gondot, nyilvan fugg ez attol hogyan vegzodik naluk a tartalom.

- Neked mint tartalomszolgaltatonak a fo celod az, hogy a szolgaltatasod es a usered kozotti utvonal minnel nagyobb reszet tud valamilyen szinten monitorozni/kontrollalni, ha atdobod a multicast forgalmat az eyeball ISP-nek, onnantol kezdve sokkal tobb mulik rajta, mint elotte. Tobbszereplos esetekben nagyon nehez a debuggolas, amikor minden szereplo csak egy kis reszet latja a folyamatoknak.

- A netflix jelenleg ~18-20k cache servert telepitett le itt-ott ISP-knel, ez egy standard es (mar) bejaratott "konnyu" feladat, de ha multicast-ot akarsz ennyi ISP-vel vagy csak a nagyobbakkal, ott minden eset mas es mas lesz,
vegtelen meetingek es egyeztetesek hada. Ez nem az a kategoria amikor a HMX atlogat egy kabelt a Deninet-nek a VH-ban, hogy akkor itt kapod RTL-t meg a TV2-ot.

A p2p-nel ismet bejon kicsit a kontroll hianya, illetve a compliance/legal team is valoszinuleg keresztbe fekszik jogos vagy nem jogos ervekkel.

Ami kimaradt,

- bar live az esemeny ez nem egy linearis TV adas, van X usered aki X percel kesobb kezdte el nezni es nem beletekert, hanem o ezzel a delay-el akarja nezni vegig es egyeb hasonlo igenyek/problemak

Építettem már multlcast hálózatot, és szerintem nem itt vagyok itt egyetlen, aki  ismeri, hidd el, tudjuk, mi az az IGMP meg a PIM. Arra van tipped, miért az első dolga az ISP-nak letiltani a hálózatán a multicast forgalmat? 

Persze lehet azzal kontrázni, hogy a PopcornTime nem is liveozásra lett kitalálva de talán nem nehéz belátni, hogy nem túl bonyolult live funkcióval kiegészíteni

Nekem elég nehéz belátni, hogy egy (ad absurdum: adaptív) live streamet hogyan skálázol több száz millió végpontra egy torrent-like megoldással, úgy, hogy azok véletlenszerűen jönnek-mennek, vagy tudnak más végpontokkal beszélni, vagy nem, vagy van elég sávszélességük lefelé/felfelé, vagy nem stb. Mindezt úgy, hogy stabilan kell 3-30 Mibps streamet tartanod, anélkül, hogy a pufferből kiszaladnál.

Ha ez szerinted "nem túl bonyolult", megosztanád a műszaki elképzeléseidet egy ilyen rendszerről?

Pontosan honnan hiányolod a multicastot egy Netflix-féle live streaming szolgáltatásnál?

( asch v | 2024. 11. 16., szo – 11:56 )

>akkor mi lehetett a probléma?

A Netflix nem a Hupról veszi fel a dolgozóit. Simple as.

Kiváncsi lennék a számokra, hogy hány egyidejű néző volt (lett volna). Nem volt még nagyobb live streaming esemény, ami gond nélkül lement? El tudom képzelni, hogy nem a Netflix volt a hunyó, hanem a hálózat nem bírta a terhelést. Ha mondjuk egy szolgáltatónak a routerei telítődnek és amiatt nem működik a streaming, akkor azzal a Netflix semmit nem tud csinálni (a jelenleg divatos technológiák mellett).

Ha belegondoltok az élő események streamingjét meg lehetne oldani úgy is, hogy a hálózat minden csomópontjához 1db stream megy, és a hálózati elem osztja szét mindenkinek ugyanazt. Így biztosan működött volna, csak hát a privacy miatt mindenkinek közvetlenül a Netflix szervereihez kell csatlakozni (https protokollon), és így a forgalom megsokszorozódik mind a szervereken, mint a hálózaton. Ki kellene dolgozni egy szabványt erre is, hogy a hálózati szolgáltatónál lehessen végződtetni az SSL-t például.

És mi lett a vége a küzdelemnek? (Nem, nem fogom megnézni, annyira nem érdekel.)

Mint mindig a problema nem ilyen egyszeru, mi van ha kesletetve nezem, megallitom. Mint mindennek gondolom az online stremingnek is megvan a sajat domain tudasa amit csak akkor tudod ha csinalod 1000 millio kis buktato, scenariok amik nem latszanak abbol ahogy hasznalod. Aki komolyabban foglalkozott complex rendszerek fejlesztesevel tudja hogy ezt 0-rol felszedni nagyon nehez. Ez en cegemnel is minimum fel - 1 ev mire egy senior fejleszto beletanul es kb erti mit es miert csinal.

+1

A Netflix személyreszabott CDN megoldása az Open Connect Appliance (OCA).
Program: Netflix Open Connect; https://openconnect.netflix.com/Open-Connect-Overview.pdf 

Fizikailag legközelebb Magyarországhoz a nyilvános infók alapján Bécsben van ilyen Open Connect kapcsolódás, de nyilván a nagy ISP-k a saját backbone-jukon hozzák be az országba a netflix tartalmakat, és ott peer-elnek, a belső infrájuk pedig nyilván üzleti titok (de gondolom ott még vannak ilyen OCA-k, esetleg saját CDN-be van integrálva a Netflix tartalom is).

Lehet, hogy ez a streaming ettől független infrán ment, de inkább valószínű, hogy a meglévő megoldásukat tunningolták erre a sportközvetítésre, és valószínűleg a ISP-k egy eseményre nem fejlesztették/konfigurálták a saját részüket.
Ha a Netflix-nek sikerül a real-time sportközvetítés piacra betörni, akkor majd jobb lesz. Gondolom.   

Egy jo eloadas toluk a temaban https://www.youtube.com/watch?v=0G5BolDEwvw

Egyebkent ha megnyitod a fast.com-ot akkor lathatod hogy van-e a kozeledben OCA mondjuk egy az IPvFoo segitsegevel, de a beepitett toolokal is meg tudod nezni honnan probalja tolteni a stuffot.
Itt pedig megnezheted hol van PoP-juk https://openconnect.netflix.com/en/peering/#internet-exchange-participa… vagy peeringdb

( kikadff v | 2024. 11. 16., szo – 12:29 )

Netflix skálázódik max X-re, és most a leterheltség nagyobb volt mint X?

Magyar szerverek _nem_ skálázódnak, ezért ha nagyobb terhelés van rögtön letérdel?

A magyar állami informatika még ott tart, hogy basszunk alá egy combos szervert és majd az elbírja (tapasztalat). Ha nem, akkor túlterheléses támadás.

Biztos igazad van, pont igy működik az online pénztárgép projekt, az e-magyarország, az eeszt, a nav adatbányász datalake-je és még száz másik állami IT projekt. Mind-mind 1 darab combos szerves.

(amikor a politikai vakultság átveszi az irányitást a szakmai értelem fölött, akkor születnek ilyen nagy butaságok)

Nem tudom, hogy mire látsz rá, de a kijelentésed, hogy a magyar állami informatika itt tartana, az tényszerűen nem igaz.

Nagyon komoly rendszerek készültek az utóbbi években és elég jól is futnak. (de nyilván léteznek 1 gépes játék-rendszerek is)

Biztos igazad van, pont igy működik az online pénztárgép projekt, az e-magyarország, az eeszt, a nav adatbányász datalake-je és még száz másik állami IT projekt. Mind-mind 1 darab combos szerves.

Ezek egyike se skálázható, össze is omlottak, összeomlanak és össze fognak omlani, amikor fixen letett szerverpark kapacitását eléri az igény és ugyanúgy fizetni kell éjjel és hétvégén is, amikor töredéke a terhelés, de végülis pénz van rá, hiszen nem profitorientált cég és nincs versenytárs se, ami olcsóbb lenne és átmenne oda az ügyfél, mert nem tud.

https://iotguru.cloud

Nem skálázható? Tehát azt mondod terveztek egy 500 szerveres elosztott rendszert, ami szépen működik, de nem lehetne egy 501. szervert betenni, hiszen nem skálázható? Itt most tényleg valami verseny megy, ki tud nagyobb hülyeséget összehordani?

Egyáltalán tudod honnan indult a szál? Hogy az állami IT még ott tart, egygépes, combos szervereken üzemeltet szolgáltatásokat, amiről nyilván kiderült, hogy komplett hülyeség. Ezek skálázható, sokszáz-ezer gépes elsztott rendszerek, amik kurvára skálázhatóak. Hogy lefelé ne lennének skálázhatóak, azt se tudom milyen agymenésből gondolod, de összevág a többi zagyvasággal.

Hogy már a fillérbaszást is belekevered, csak hogy valami még nagyobb hülyeséget mondjál, az tényleg csak hab a tortán, és nyilván arról sincs halovány fogalmad sincs, hogy mennyibe kerül és hogy mennyivel lenne olcsóbb valami publikus pistike bt-hez vinni. (és hogy menne a sikoltozás, ha valami publikus felhőbe nyomnák az adatokat)

Nem skálázható?

Nem.

Tehát azt mondod terveztek egy 500 szerveres elosztott rendszert, ami szépen működik, de nem lehetne egy 501. szervert betenni, hiszen nem skálázható?

Egyrészt nem csináltak 500 szerveres elosztott rendszert. Másrészt a skálázható rendszer nem azt jelenti, hogy be lehet-e tenni egy n+1 szervert, hanem azt, hogy a rendszer teljesítménye ettől n+1 lesz. Igen nagy különbség.

Itt most tényleg valami verseny megy, ki tud nagyobb hülyeséget összehordani?

Fogalmam nincs, te szoktál gyakran hülyeségeket írni. :)

Használtad például már az ÁNYK-ból a közvetlen dokumentum feltöltést? Na, annak a szerver oldalát én írtam.

Hogy az állami IT még ott tart, egygépes, combos szervereken üzemeltet szolgáltatásokat, amiről nyilván kiderült, hogy komplett hülyeség. Ezek skálázható, sokszáz-ezer gépes elsztott rendszerek, amik kurvára skálázhatóak. Hogy lefelé ne lennének skálázhatóak, azt se tudom milyen agymenésből gondolod, de összevág a többi zagyvasággal.

Ahja, az állami IT ott tart, hogy jó előre meg kell rendelni mindent és nincs olyan, hogy a forgalomtól függően skálázható, hanem be van tervezve egy maximális terhelés és annyi van megvásárolva. Ne téveszen meg, hogy felhőt írnak itt-ott, az nem az a felhő, amire te gondolsz ilyenkor. Amúgy melyik az a skálázható sokszáz-ezer gépes elosztott rendszer, amiről beszélsz?

Hogy már a fillérbaszást is belekevered, csak hogy valami még nagyobb hülyeséget mondjál, az tényleg csak hab a tortán, és nyilván arról sincs halovány fogalmad sincs, hogy mennyibe kerül és hogy mennyivel lenne olcsóbb valami publikus pistike bt-hez vinni. (és hogy menne a sikoltozás, ha valami publikus felhőbe nyomnák az adatokat)

Remek szalmabábjaid vannak. :D

https://iotguru.cloud

"Másrészt a skálázható rendszer nem azt jelenti, hogy be lehet-e tenni egy n+1 szervert, hanem azt, hogy a rendszer teljesítménye ettől n+1 lesz. "

Újabb hülyeség. Ha ez igaz lenne, akkor egy-két skálázható rendszer létezne a világon, az is valami nagyon speciális feladatot végezne. Lineárisan skálázódó rendszer gyakorlatilag nem is létezik, mindig lesz bottleneck és sosem nő n+1 szerver berakása után n+1-el a rendszer "teljesitménye"

Nyugodj bele, a sok gépes rendszerek skálázhatóak, mindegyik amit emlitettem. Nem linerárisan és nem a végtelenségig, ahogy egyetlen rendszer sem. (a topic megvan, amiben irogatsz?) De ezek elosztott rendszerek, microservice architektúrában, bizony skálázhatóak.

"Használtad például már az ÁNYK-ból a közvetlen dokumentum feltöltést? "

Használtam, nem véletlen nem emlitettem, az ányk-nál kevés nagyobb hulladék rendszer van az állami oldalon. Hogy egygépes-e a szerver oldala, azt nem tudom, bár kétlem. De hogy egy hulladék-szar, az biztos.

Először fogd fel, hogy mit jelent a skálázható rendszer - mivel egyáltalán nem azt amit te elképzelsz, kevered a dynamic- és auto-scale-el - utána fogd fel miről szól a szál - állitólagos egygépes állami rendszerekről - utána térjünk vissza a dologra.

Újabb hülyeség. Ha ez igaz lenne, akkor egy-két skálázható rendszer létezne a világon, az is valami nagyon speciális feladatot végezne. Lineárisan skálázódó rendszer gyakorlatilag nem is létezik, mindig lesz bottleneck és sosem nő n+1 szerver berakása után n+1-el a rendszer "teljesitménye"

Hogyne létezne lineárisan skálázható rendszer, pláne nem speciális feladattal. Az, hogy ezekről és így nem tudsz és hülyeséget beszélsz, az baj.

az ányk-nál kevés nagyobb hulladék rendszer van az állami oldalon

Ezzel egyetértek. Azzal is, hogy van sok egyéb hulladék rendszer állami oldalon.

Hogy egygépes-e a szerver oldala, azt nem tudom, bár kétlem. De hogy egy hulladék-szar, az biztos.

A szerver oldalának nincs köze ahhoz, hogy az ÁNYK fos, de amúgy a szerver oldala is fos. :D

Szóval ott tartunk, hogy van egy csomó fos része az állami informatikának és vannak azok, amelyekről írsz, csak nem tudod megmondani, hogy melyik az.

Először fogd fel, hogy mit jelent a skálázható rendszer - mivel egyáltalán nem azt amit te elképzelsz, kevered a dynamic- és auto-scale-el - utána fogd fel miről szól a szál - állitólagos egygépes állami rendszerekről - utána térjünk vissza a dologra.

Szerintem te erősen kevered a scaling és clustering fogalmakat...

https://iotguru.cloud

"Hogyne létezne lineárisan skálázható rendszer, pláne nem speciális feladattal. "

Mesélj pár linárisan bármeddig skálázható rendszerekről, főleg olyanokról amelyek a témába vágnak, netes szolgáltatást nyújtanak pl. állami szinten.

"szóval ott tartunk, hogy van egy csomó fos része az állami informatikának"

Nem. Egyelőre ott tartunk, hogy hoztam egy LISTÁT a jól működő, skálázható elosztott állami fejlesztésű rendszerekről, annak cáfolására, hogy az állam csak egyszerveres monolit rendszereket tudna létrehozni-üzemeltetni. Erre te jöttél minden hülyeséggel és ezt az állitást még abban a rendszerben sem sikerült megcáfolnod, aminek egy részét állitólag te irtad...

"amelyekről írsz, csak nem tudod megmondani, hogy melyik az."

Érted is amit olvasol? Nem egyet hoztam, hanem egy rövid listát...

"Szerintem te erősen kevered a scaling és clustering fogalmakat..."

Te keversz itt valamit nagyon. A clustering aztán végképp tökmás, az gyakran nem is skálázódásra van, hanem rendelkezésre állásra.

Szerintem maradjunk annál a nonsense-ednél, hogy szerinted csak az a skálázható rendszer, ahol lineárisan skálázódik a teljesitmény minden egyes új szerver beállitásával.

Mesélj pár linárisan bármeddig skálázható rendszerekről, főleg olyanokról amelyek a témába vágnak, netes szolgáltatást nyújtanak pl. állami szinten.

Tervezés kérdése, de jelenleg magyar állami szinten nincs ilyen rendszer, mert már a tervezésnél elbukik ez az igény.

Egyelőre ott tartunk, hogy hoztam egy LISTÁT a jól működő, skálázható elosztott állami fejlesztésű rendszerekről, annak cáfolására, hogy az állam csak egyszerveres monolit rendszereket tudna létrehozni-üzemeltetni.

A listád egyike se elosztott, se nem jól működő, ezek tipikusan monolitikus vagy mikroservice architektúrának álcázott monolitikus rendszerek valamilyen fix erőforrású clustering architektúrában, ahol többé-kevésbé az adatbázis réteg tartja a state-et, és amelyeket képtelenség fel és leskálázni az igényeknek megfelelően, mert nem úgy tervezték őket.

Te keversz itt valamit nagyon. A clustering aztán végképp tökmás, az gyakran nem is skálázódásra van, hanem rendelkezésre állásra.

Hajjajj, nyilván, én keverek... mondd, te hány ilyen jellegű rendszer tettél össze eddig? :D

Szerintem maradjunk annál a nonsense-ednél, hogy szerinted csak az a skálázható rendszer, ahol lineárisan skálázódik a teljesitmény minden egyes új szerver beállitásával.

Ez nem szerintem így van, hanem ez a definíciója, az a rendszer, amelyik resource duplázással nem lesz képes dupla teljesítményre, az egy nem skálázható rendszer:  "a system is scalable in the range where marginal cost of additional workload is nearly constant."

https://iotguru.cloud

:off

"de amúgy a szerver oldala is fos. "

Speaking of... tudod, hogy kihez lehet fordulni az anykgw.gov.hu hibás tanúsítványával kapcsolatban? A 1818-nál a "telepítse újra a java-t, majd frissítse a legújabb abevjava-ra" típusú supportnál nem jutok tovább. Az Idomsoft volt még tipp, ott a levele továbbítva az illetékes csoport felé üzenet óta semmi, a NISZ-től még automata választ sem kaptam.

:on

Speaking of... tudod, hogy kihez lehet fordulni az anykgw.gov.hu hibás tanúsítványával kapcsolatban?

Nem hibás, by design a root CA privát... :D

A 1818-nál a "telepítse újra a java-t, majd frissítse a legújabb abevjava-ra" típusú supportnál nem jutok tovább. Az Idomsoft volt még tipp, ott a levele továbbítva az illetékes csoport felé üzenet óta semmi, a NISZ-től még automata választ sem kaptam.

Mi nem megy miatta?

https://iotguru.cloud

Eddig minden allami rendszer a kovetkezo modon tortent:
-Ujsagban megirjak 20-an, hogy kovetkezo honap 1-en elindul az uj XY rendszer, vegre nem leszunk annyira lemaradva, emberek ujjonganak
-Eljon honap elseje, emberek elkezdik hasznalni XY-t, a rendszer lehal
-Masodikan: "Tulterheleses hackertamadas erte XY rendszert"

Ez nekem nem tunik valami skalazhatonak. Nem latok bele (nem mennek ilyen NER-es helyre), de ha 500 serveres elosztott rendszerrol lenne szo, amibe akarmikor beteheto meg egy, akkor nem ez tortenne minden egyes alkalommal. A tunetekbol kovetkeztetni lehet a problemakra.

A strange game. The only winning move is not to play. How about a nice game of chess?

Melyik az, amelyik nem rohadt le még? A NAV pénztárgépet azért nem látod lerohadni, mert a pénztárgép lerohadáskor bufferel és beküldi utólag és ebből te semmit nem veszel észre; a NAV online számla same in english, csak az látszik, hogy a számlázó bufferel; az EESZT már többször is lerohadt, amikor használni akarták többen, mint a normál napi terhelés; és így tovább. Az állami rendszerek elsöprő többsége nem skálázható, kiépítették egy fix kapacitással, aztán ha alatta van a terhelés, akkor fizetünk feleslegesen, ha felette van, akkor meg lerohad. Mondj már egy olyan állami rendszert, ahol ki-be kapcsolják a szervereket és ettől olcsóbban üzemeltethető, eddig csak olyat mondtál, ami nem ilyen.

https://iotguru.cloud

Ha az általad felsorolt szolgáltatások _backend_-jét nem tudja egy combos szerver ellátni, akkor szarul van implementálva :)

Hint: sacc/kb. történik egy munkanapon max. 10 db. fizetés/fő.

Az ~1000 tranzakció/sec. Ne már egy bika szerver ne bírja el! De még csúcsban sem lesz több mint 20x-osa.

( ricsip v | 2024. 11. 16., szo – 13:49 )

Netflix majd megosztja az RCA-t pár napon belül. A legközelebbi konferencián esélyes h. lesz netflix engineer-től YT-on megnézhető előadás a témában.

Valóban szomorú, h. ezt a tudást autodidakta módon egyszerűen nem lehet felszedni sehogy máshogy. Ha ehhez tényleg érteni akarsz, muszáj vagy valahogy bejutni egy google, netflix, meta-hoz, amazonhoz v. mikroszofthoz, h. ilyen nagyságrendű infrával képbe kerülj. Aztán eltölteni 10-15 évet, miközben jutsz feljebb a ranglétrán, mert alsó szintű üzemeltető droidként sosem lesz lehetőség látni a nagy egészet. Ez nem az a játszótér, h. max. előfizetsz egy havi 10 dolláros VPS-re amin ki tudod tesztelni.

Ugyanitt jelentkezhetnek az atomerőmű üzemeltetésben jártasak, a Burj Khalifa méretű épületeket megépíteni képes emberkék, és még millió más terület top 1 ezrelék expertjei.

( _ventura_ v | 2024. 11. 16., szo – 14:57 )

Nincsen itt semmi látnivaló, a gond az volt, hogy nem nem offline, hanem online tartalom.

A netflix és hasonló szolgáltatók a tartalmalmakat a ISP-khez letolt szerverekről szolgálják ki, éjjel letöltik a filmeket és igazából, ott helyben nézi a helyi ügyfél. Live streamnél ilyen lehetőség nincsen. Így a sávszélesség igény, globálisan is többszöröse a megszokottnak ...

Fedora 41, Thinkpad x280

Live-nal is megvan a lehetoseged, hogy az ISP-kez lerakott serverek offloadoljanak, azt nemtudom, hogy az OCA-k kepesek-e erre, de az biztos, hogy nem erre lettek kihegyezve.

Egyebkent ezt az ejjel letoltjuk nappal kiszolgaljuk dolgot kb csak ok csinaljak, kb minden masik streaming szolgaltato 3rdparty generic cdn-ekkel dolgozik, ahol bar tudnak pre-warmingolni, de az azert nem ugyanaz.

( kris | 2024. 11. 16., szo – 15:15 )

Szerkesztve: 2024. 11. 16., szo – 15:16

<Lassan írok :)

Logikusan gondolkodva, de csak egészen általánosságban: a Netflix egy on-demand szolgáltatás, ami teljesen más tészta, mint a live streaming. A Netflix technológiailag az on-demand-ra van kihegyezve, ezért is tesznek le minden ISP-hez egy (több?) Netflix szervert, hogy a tévénézők minél közelebbről tölthessék le a filmeket (amiket ott helyben a Netflix szerverein tárolnak). A live streamingnél erre hiába játszol... nyilván a Netflix szerver live streamingnél is hihetetlen előny, mert ugye a közvetítő szervernek csak annyi klienst kell kezelni, ahány Netflix szerver van. De ettől függetlenül nem ez az, amit mindig is csináltak eddig, tehát bárhol elcsúszhattak a banánhéjon.

Most megnéztem a downdetector-on, már a meccs előtt kezdődtek a problémák: https://downdetector.com/status/netflix/ lehet, hogy nem is (csak) a live streaming volt a probléma, hanem több egymástól független dolog játszhatott be és a meccs csak rátett egy lapáttal. Nem lehetett könnyű estéje a technikai csapatnak --- ha adnak ki RCA-t biztos érdekes lesz.
 

Kb a cloudflare és a netflix azok akiknek komolyan vehető RCA doksijaik vannak. Mikroszoft csak akkor készít jó RCA doksikat, ha épp a faszukat akarja levágni az egész világ valami kolosszális.elbaszás miatt. A kisebb RCA-ik a "..hmm valami miatt nem ment, átterheltem egy másik DC-re... solved, ticket closed"

( Caro | 2024. 11. 16., szo – 19:41 )

Ja, hát streamelni szeretnénk a fél világnak, de a global multicast-ot még továbbra sem valósítottuk meg.

Pedig az ilyen helyzetekben nem kevés sávszélességet lehetne megtakarítani. Persze addig, amíg mindenki élőben nézi, és egyszer sem állítja meg a felvételt, bár éppenséggel ezt is meg lehetne oldani némi kompromisszumokkal a kliens oldalon.

( _Franko_ v | 2024. 11. 16., szo – 19:57 )

Szerkesztve: 2024. 11. 16., szo – 20:03

Elmérték az igényeket, nem skálázták fel időben és előre annyira az infrastruktúrát, amennyien végül kíváncsiak voltak rá: 120 milliónál több néző esett be végül, a 280 milliós ügyfélkör több mint harmada, majdnem fele. Összehasonlításul, az Olimpia live stream esetén 30 millió néző volt a maximum a több hetes esemény alatt és ott nem voltak ilyen rövid és ilyen hirtelen felfutások. Hirtelen beeső nem várt terhelést egyszerűen nem tudsz kiszolgálni, ha nem tudod előre felmérni a várható terhelést, akkor az össze fog omlani, legyenek ott a legjobb szakemberek és a legjobb rendszerek, a resource pool ott kell legyen előre.

Amit letettek az asztalra, az több mint amit eddig bárki tudott, összevetésül, az X/Twitter Spaces például 500-600 ezer nézőtől összeomlott idén nyáron többször is és abban nem volt videó, csak hang, a YouTube stream maximum nézőszáma 8 millió volt eddig, a legnagyobb Twitch nézőszám 3,8 millió volt.

Nekik beesett 120 millió és 120 millióig röccenés nélkül fel tudták felskálázni, utána jöttek a bajok, valószínűleg erre a számra terveztek, mint worst case scenario, hogy ennyi úgy se lesz. Lett.

https://iotguru.cloud

Sámsonról elterjed a hír, hogy buzi. Mikor a fülébe jut nagyon ideges lesz. Kihirdeti hogy vasárnap az arénában 1000 nőt tesz magáévá. Eljön a vasárnap megvan az 1000 nő és megtelik az aréna nézőkkel. Sámson nekilát. 500-ig simán bírja. 600-nál piheg. 700-nál kezd kifulladni. 800-nál remeg a lába. 979 után feladja. A tömeg őrjöngése hirtelen abbamarad, majd skandálni kezdik: Sámson buzi, Sámson buzi.

Na, ilyen ez. :D

https://iotguru.cloud

Ezek az 500k - 4-8millio eleg kis szamoknak tunnek. Nem hiszem hogy mas sport esemenyeknel ( akar boksz , foci vilagbajnoki donto stb ) vay teljesen mas esemenyeknel ne lennenek nagyobb szamok.

En 400-500k nezo szolgaltam ki, de maga a stream egyszeru volt/egyszerunek tunik : 1-2 origin majd a CDN problemaja. A korulotte levo cucc ( maga a site, analytics fogadasa stb ) mar mas teszta. Es en egy viszonylag senki vagyok.

Itt egyertelmu hogy ok sajat maguk a CDN,meg sokkal tobb nezo, meg tippelni sem akarok hogy mi volt a gond

Nem hiszem hogy mas sport esemenyeknel ( akar boksz , foci vilagbajnoki donto stb ) vay teljesen mas esemenyeknel ne lennenek nagyobb szamok.

Ezeket tipikusan nem stream-en nézik, hanem "hagyományos" csatornákon. Mondok példát, a 2023-as Super Bowl esetén volt 113 millió néző, csúcsban 7 millió stream néző és ezt több stream platform hozta össze és ott is voltak problémák: "In its 2023 Super Bowl streaming survey, Phenix found that every streaming service delivered inconsistent speeds across their customer base; for instance, while someone watching Fubo might have experienced a 45-second lag behind the on-field action [...]"

1-2 origin majd a CDN problemaja. [...] ok sajat maguk a CDN

Ennyi.

https://iotguru.cloud

Termeszetesen hagyomanyos csatornakon nezzik azokat. De ha csak 10% nezzi az mar 13 millio, 7 meg kevesnek is tunik .

Talan Europaban nagyobb szamok is lehetnek? Gondolok arra hogy itt per orszagonkenti kozvetitesi jogok miatt inkabb elofordulhat hogy sokan nem erik el hagyomanyos csatornan

 

Ettol fuggetlenul erdekesnek talalom hogy pont live stream-en fordult elo, en VOD-ot nehezebb problemanak talalom. Bar igaz VOD-on soha nem lattam live-ot megkozelito ertekeket

De ha csak 10% nezzi az mar 13 millio, 7 meg kevesnek is tunik.

Lehet, hogy kevésnek tűnik, de egyszerűen ez a helyzet.

Talan Europaban nagyobb szamok is lehetnek? Gondolok arra hogy itt per orszagonkenti kozvetitesi jogok miatt inkabb elofordulhat hogy sokan nem erik el hagyomanyos csatornan

Ha nem érik el hagyományos csatornán, akkor a stream se érhető el. Tömegek meg nem baszkolódnak VPN-el.

Ettol fuggetlenul erdekesnek talalom hogy pont live stream-en fordult elo, en VOD-ot nehezebb problemanak talalom. Bar igaz VOD-on soha nem lattam live-ot megkozelito ertekeket

VOD eléggé jól jósolható, hogy mikor mennyien nézik, itt egyszerűen fogalmuk sem volt arról, hogy mi fog beesni, gyakorlatilag a 2023-as Super Bowl összesített peak nézőszámát túllépték úgy, hogy csak saját előfizetőknek ment a műsor.

https://iotguru.cloud

+1

nagyon kemény amúgy, hogy arról beszélünk, hogy 12,5 magyarországnyi ember akart nézni valamit egyszerre, és azon matyiznak emberek, hogy megreccsent a streaming

megkockáztatom, hogy az itt okoskodók mindegyike (magamat is beleértve) megközelítőleg sem dolgozott ekkora terhelésű rendszerrel, de nagyon-nagyon messziről sem, viszont a pofázás azért megy rendesen

( willy v | 2024. 11. 17., v – 02:11 )

Azért meglepő ez, mert itt a HUP-on (saját bevallásuk szerint) számos szakértő van, aki kisujjból kiráz egy olyan rendszert, ami on-demand skálázódik az igényeknek megfelelően.

Egyre többször fordul elő, amikor ide szánt szakmai tartalmakba a szakmaiságot teljesen figyelmen kívül hagyó érzelmi alapú kijelentések jelennek meg.  

( dejo v | 2024. 11. 17., v – 03:12 )

Szerkesztve: 2024. 11. 17., v – 03:13

Hátha nem fognak többet ilyen tartalmat szolgáltatni!

Én például a sport tartalmakért a sport csatornákra fizetnék elő nem a Netflixre!

Nem is értettem az ezzel kapcsolatos hírleveleket.

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( golgota | 2024. 11. 17., v – 15:14 )

Trey, te inkabb ne akard megerteni :D

( Cserek13 | 2024. 11. 17., v – 22:27 )

Szerkesztve: 2024. 11. 17., v – 22:29

A pufferelés nem az izgalom/pénz/új előfizetők vonzàsàra lett beiktatva?Mint példàul izgalmas percekben ,egy műsorban reklàmokat vàgnak be?

( dyra | 2024. 11. 20., sze – 12:02 )

Nem számítottak ekkora nézettségre. Nem hiszem volt más gond.