Miben irnal tobbmillio useres chatet

 ( carlcolt | 2017. augusztus 12., szombat - 21:30 )

Ma el kene kezdened egy chatprogram protokolljanak/szerverenek implementalasat. Van ra realis esely, hogy tobbmillio aktiv usered lesz (elmeleti sik, de tegyuk fel).

Ami kell: webes kliens, iOS kliens (gyors es nativ, + notificationok settingekkel), Android kliens

Milyen nyelvben es milyen technologiaban, protokollokban, stb. gondolkodnal? Milyen DB-t hasznalnal?

Mi az amit, biztosan nem hasznalnal?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Amit en biztosan tudok:

A szerver nem NodeJS es nem PHP - nincs teljesen implementalt multithread (nem, a workerek JS-ben nem eleg jok, volatile valtozo pl. nincs)

Websocket eleg jonak tunik, es konnyen megy Androidon meg iOS-en is, nemcsak weben.

Ja apro kiegeszites: eleg ha modern bongeszokben mukodik.

A weboldal tolem lehetne php-ban ;)


// Happy debugging, suckers
#define true (rand() > 10)

Az siman, de a chat daemonja hatarozottan nem abban kene legyen :P

amit hasznalnek: c++, protobuf, redis, (esetleg)kafka
amit nem: nodejs


// Happy debugging, suckers
#define true (rand() > 10)

Mar azt hittem nem vagyok normalis, hogy C++-ban gondolkodok. Tobben leszavaztak szemelyes ismeroseim kozul mert "jatekfejlesztok is csak azert hasznaljak mert muszaj a performance miatt". Pedig nagyon logikus valasztasnak tunik nekem ide. Megnyugtattal :)

Az elszaporodo nodejs pistikek es php jozsikak ertelemszeruen leszavazzak, mert segghulyek hozza, kenyelmetlennek itelik. C++ -hoz nagyon, C -hez meginkabb erteni kell, hogy az ember ne szart csinaljon.
Ha kell a performance es az ember nem akarja a vilag penzet vasra kolteni (lehet, de minek?) akkor egyertelmu a valasztas.
Egyebkent meg egy kulcsszo ami eszembe jutott, igaz c++ -hoz, de libev


// Happy debugging, suckers
#define true (rand() > 10)

Könnyebbség, hogy a websocket protokolljához is van már C library, ráadásul a linux disztribúcióban.

$ apt-cache search libwebsockets-dev
libwebsockets-dev - lightweight C websockets library - development files

Egyébként a sok-sok évnyi C után ilyen jellegű feladatokhoz éppen a Go-val szemezek. De még az elején vagyok, csak néhány egyszerűbb programot írtam Go-ban.
Fordítása gccgo-val. Performancia jónak tűnik, elsőre <10% a C-hez képesti lassulás, ennyit pedig a hülyebiztossága megér.
Makefile készíthető hozzá, így könnyű rendszergazdaként telepíteni a programomat (make && make install).

Websocket lib szintén van hozzá:
$ apt-cache search golang-websocket-dev
golang-github-gorilla-websocket-dev - Go package implementing the WebSocket protocol
golang-websocket-dev - Transitional package for golang-github-gorilla-websocket-dev

A websocketes chat programhoz itt egy alap példa:
https://github.com/gorilla/websocket/tree/master/examples/chat

pont a go-t akartam en is irni, nem nagyon ertek hozza, 3-4 eve atirtam egy egyszeru kis graf konyvtarat, ami megvolt c/c++ ban, 10-15%-nal nem mertem nagyobb kulonbseget, raadasul nem gccgo-t hanem original go-t hasznaltam. azert is gondoltam a go-ra mert egy jo ismerosomtol (na jo, a fiamtol) nagyon jokat hallok rola...

A go nálam no-go lenne néhány csúnyaságuk miatt: https://github.com/darlinghq/darling/issues/193

Nem tudom, próbaként bedobtam a példát egy fájlba és

package main
func main(){}

$ gccgo-7 -Wall -O2 teszt.go -o teszt
$ ./teszt

lefordult és le is futott hiba nélkül.

Ez szép, de a linkelt hibajegy nem erről szól.

Nem sikerült képbe kerülnöm. Össze tudnád foglalni, hogy milyen esetben kerülhetünk hasonló problémával szembe?
Azért érdekel, mert most tanulgatom a Go-t és az érdemes/nem érdemes megtanulni még nem lefutott kérdés.

Játékfejlesztők azért használnak c++-t szerver oldalon mert a kliens oldalon is azt használnak, így aki szerver oldal kódját csinálja, az a kliens oldal releváns részén is tud dolgozni (legtöbb framework c++). Kisebb indie cégeknél az életet jelenti, hogy nem kell eggyel több fejlesztő, nagyobb cégeknél meg praktikus azonos technológiát használni. Nem performance muszáj miatt.

kb ez nettó faszság ;)
A játékok 99%-nál (amik jól megvannak tervezve), ugyan az a kliens/szerver oldali codebase van, senki nem dolgozik "külön". Persze, biztos vannak olyan esetek (matchmaking rendszer, stb.) de azt meg kb bármiben megírhatod


// Happy debugging, suckers
#define true (rand() > 10)

ugyan azt írtad amit én csak pepitában.

Én C-re gondoltam. :)

Érdekelne, hogy mik az érvek a nodejs ellen.
Én csak most ismerkedek vele, eddig pár apró programot írtam szerver oldalra, és eddig nagyon meg vagyok vele elégedve.
Nem mondom, hogy a C++ butaság lenne, vagy hogy a nodejs a jobb, de az eddigi tapasztalataim alapján nagyon jól skálázódik, gyors, és nem okoz gondot neki sok szálon feldolgozni. (szóval nem tapasztaltam azokat, amiket negatívumként olvastam a szálban)

Csak annyi a baj, hogy átdobod a szart a szomszédba... addig skálázható, amíg az alatta vagy felette lévő rendszerek skálázhatóak és/vagy maga a szolgáltatás skálázható... egy előnye van a többi hasonlóan skálázható és gyors megoldáshoz képest: ha épp nincs elérhető backend fejlesztő, akkor oda lehet ültetni egy frontend fejlesztőt is.

Ne 10 userben gondolkodj (meg tesztelj), hanem 10.000-ben.

Ezt linkelte már valaki? https://www.semitwist.com/mirror/node-js-is-cancer.html

Példák:
Single Threaded, mint a böngészőben. IO műveletek és a callback-ek mentén szeleteli fel a requestek végrehajtását (á la böngészőkben), azaz ha egy függvényed erősen CPU zabáló, eleszik mindent a többi request elől. Példa: Fibonacci :D Internet Által Javasolt Megoldás(tm)? Sok-sok szerver és durva microservice architektúra. Vagy forked-off és külön úton visszatolt eredmény :) Vagy mindent tárolt eljárásba raksz és a DB-re tolod a melót.
A callback függvények ugye aszinkron módon futnak (lásd: böngészőkbeli event loop model), tehát a hibák propagációja tervezhetetlen (pl: try-catch rég nem létezik, mire a kódod a throw-ig eljut). Hogyan? Például refaktorálsz egy nagy függvényt (vagy függvényláncolatot) és belül valamit callback-esre átírsz.

De hát szar programot bármilyen nyelvben lehet írni.

Úgy emlékszem, újabban V8 fut a nodejsben/alatt. Annak is van némi errátája: https://github.com/vhf/v8-bailout-reasons

Ne 10 userben gondolkodj (meg tesztelj), hanem 10.000-ben.

lakj :-))

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Hehe, lattam mar olyan cuccot, ami 2 (ketto, 1+1) userre is elhalt XD

na de ez milyen chat? :-)

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Elég skizo...

nem chat volt, hanem multiuser konkurrens dologbasztato, pont az volt a lenyege, hogy _egyszerre_ basztathattok dolgokat...

Gyakran futtatsz Fibonaccit a szerveren?

Látom átjött a lényeg :)

Egy bizonyos méret fölött mindenképpen vízszintesen kell skálázódnod, ez meg innentől kezdve csak tervezés kérdése, a programnyelv majdnem teljesen mindegy. A klasszikus SQL alapú adatbázisokat például teljesen el kell felejteni.

Ha relatív kevés fejlesztéssel meg akarod úszni, akkor ráépítesz valamilyen vízszintesen skálázódó keretrendszerre (pl. hadoop), de ennél is jobban jársz ha inkább nem méretezel több millió userre. Nagy valószínűséggel gazdaságilag jobban megéri kidobni az egészet és újraírni akkor amikor már tényleg szükség van rá.

Lazán kapcsolódó előadás a témában:
https://www.youtube.com/watch?v=FJByltoGnA8

+1

"A klasszikus SQL alapú adatbázisokat például teljesen el kell felejteni."

ez mit jelent?

Ami egyáltalán képes valamennyire horizontálisan skálázódni, az is csak néhány tíz node-ig, globális szolgáltatás esetén csak nagyon drága megoldásokkal lehet skálázni. (vagy nagyon ügyes sharding-gal, de akkor meg elveszted az egyszerű join lehetőségét, így nem lesz sokkal okosabb mint pl. egy nosql, akkor meg minek)

Csak az sql/nosql szerintem kicsit misnomer. Ld https://cloud.google.com/sql/ - világ szinten skálázódik, de mégis van fölötte SQL *query engine*.

oké, jogos. Hadoop fölé is lehet tenni. A lényeg hogy ne hagyományos rdbms legyen, a megfogalmazás pongyola volt, szegény query language nem tehet a db architektúrájáról :)

Ezt kifejtenéd?

Nekem úgy tűnik, hogy ez egyszerűen egy menedzselt PostgreSQL / MySQL szolgáltatás. Nem látom, hogy ez miért tudna úgy horizontálisan skálázódni mint egy NoSQL adatbázis anélkül, hogy ugyanazokat a korlátozásokat használnád az adatmodellezésben (pl. sharding, key-value storeként kezelés, egyszerűen indexelt, node-ok között megosztható queryk lehetőleg joinok nélkül)

Bocs, rossz linket küldtem.

https://cloud.google.com/spanner/

ez kb. annyira sql, mint a wine windows.

ha inkább nem méretezel több millió userre.

99,9%, hogy nem lesz ennyi online useruk 5 even belul. Eddig C-ben irkaltam demonokat, ugyhogy ebben (esetleg C++) csinalnam ezt is. Ja, a tobb millio aktiv user melle erdemes lapozgatni a c10k problemarol is. A protokollrol nehez addig nyilatkozni, amig nem tudjuk a feladat reszletesebb leirasat, pl. csak text-et kuldenek a userek, vagy multimedias cuccokat is (kepek, rovid videok, ...)

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

hadoop alapu cset :DDDDDDDDDDDDDDDDD

--
NetBSD - Simplicity is prerequisite for reliability

a hadoop alapu cset még annyira nem vicces, inkább a real-time hadoop alapu :D


// Happy debugging, suckers
#define true (rand() > 10)

Meglepodtem en is hogy egy batch adatfeldolgozasra szant megoldast hova az anyamba tegyek amikor csetet fejlesztek. :)

--
arch,debian,retropie,osmc,android,windows

"batch adatfeldolgozasra szant megoldast" ez igy nem teljesen igaz, pl: "Apache Storm is a free and open source distributed realtime computation system."

-
Go konkurencia kezelés gyorstalpaló

Én a Hadoop-ról beszéltem, annak pedig semmi köze a Stormhoz.

--
arch,debian,retropie,osmc,android,windows

Akit nálam jobban érdekel a téma nézzen utána, de szerintem a Storm maximum a HDFS -ről (a hadoop high level fájlrendszeréről) tud adatot beszippantani és real time feldolgozni. Maga a hadoop (map reduce eljárása) kizárólag batch feldolgozásra alkalmas.

szerk.: a HDFS-ről elég sokminden tud adatot olvasni, de ettől még nem lesz sok köze magához a Hadoophoz.

--
arch,debian,retropie,osmc,android,windows

A kulcs jelen esetben a Yarn, ami a Hadoop szive. A Yarn schedulalja a Storm jobokat, ergo Hadoopon futtatod. A mi Hadoop disztribucionknak resze a Storm, official supportot is adunk hozza, stb. Hadoop != map/reduce ;)

-
Go konkurencia kezelés gyorstalpaló

Köszi az egyértelműsítést. Én ott kezdtem hogy a hadoop (*as in mapreduce) batch adatfeldolgozásra való, tehát nem nagyon van helye egy online chatszolgáltatásban, ami közel real time megoldásokat kíván.

--
arch,debian,retropie,osmc,android,windows

En sem Hadooppal allnek neki, de nem azert mert nem lehetne megcsinalni, rengeteg fele framework van kulonbozo feladatokra, hanem mert agyuval nem lovunk verebre.

-
Go konkurencia kezelés gyorstalpaló

"A kulcs jelen esetben a Yarn, ami a Hadoop szive. A Yarn schedulalja a Storm jobokat, ergo Hadoopon futtatod. A mi Hadoop disztribucionknak resze a Storm, official supportot is adunk hozza, stb. Hadoop != map/reduce ;)"

Ahh, vagyis Ti így használjátok, remek. Akkor maradjunk annyiban hogy nem hadoop, hanem hadoop ecosystem és talán még igaz is lehet. Kieg.: Hadoop != map/reduce != Storm


// Happy debugging, suckers
#define true (rand() > 10)

"vagyis Ti így használjátok, remek" Ez egy opcio. Sehol nem irtam, hogy a Storm jobot csak Hadooppal lehet futtatni.

"nem hadoop, hanem hadoop ecosystem" Amugy lovagolhatunk a szavakon, foleg erdemes, mivel az egesz csak egy viccnek indult. Szoval van az Apache™ Hadoop, meg a "koznyelvben" hasznalt Hadoop aka echosystem. Nem erzem, hogy nagy hulyeseget mondtam azzal, hogy lehet Hadooppal real-time adatokat feldoglozni. Amikor elmegye a Hadoop Summitra, akkor nem az Apache™ Hadoop-rol van szo 3 napig 15 teremben, hanem a Hadooprol, az egeszrol, ami messze nem egy map/reduce utemezo/vegrehajto meg egy elosztott file rendszer.

-
Go konkurencia kezelés gyorstalpaló

Nevezzünk mindent hadoop-nak és akkor megoldva. Az hogy egy hadoop summit-on beszélnek a hadoop-hoz integrálható dolgokról kb olyan, mint ha egy linux konferencián beszének az smtp-ről. Igen és?
A hadoop ennek ellenére még egy bazinagy elosztott filerendszer és map/reduce ütemező/végrehajtó marad. Kb mintha azt mondanád hogy a weboldaladat apache-ban szeretnéd megcsinálni (oké, akkor statikus html file-ok), közben kiderül hogy php-ról beszélünk


// Happy debugging, suckers
#define true (rand() > 10)

"Az hogy egy hadoop summit-on beszélnek" az pontosan azt jelenti, hogy masok fejeben is az van, mint az enyemben, hogy amikor Hadooprol beszelnek, akkor az egeszet ertik alatta, es nem konkretan az Apache™ Hadoopot, ezert nem Hadoop and Friends Summit a neve a konferencianak. (amugy kiragadott pelda)

"kb olyan, mint ha egy linux konferencián beszének az smtp-ről" koszonom, hogy szoba hoztad :) A Linux az a kernel, de mikor az emberek a Linuxrol beszelnek nem a kernelrol beszelnek. Errol annyi vita ment mar, de a koznyelv megis igy hasznalja.

-
Go konkurencia kezelés gyorstalpaló

"A Linux az a kernel, de mikor az emberek a Linuxrol beszelnek nem a kernelrol beszelnek"
Pontosan, de nem is akarják a postfix smtpd-t és az nginx webszervert linux-nak nevezni egységesen, csak mert némi köze van hozzá :)


// Happy debugging, suckers
#define true (rand() > 10)

Jah, de ha az a feladat, hogy szolgalj ki Linuxon statikus HTML-t, es te feltelepitesz/konfiguralsz egy nginx-et, akkor megoldottad a problemat vagy sem?

-
Go konkurencia kezelés gyorstalpaló

Rendben van! Nyertél! Akkor a hadoop-nál nagyobb ultimate joker a Linux szó. Kedves eredeti kérdező: a problémád megoldható linux-ban!


// Happy debugging, suckers
#define true (rand() > 10)

Igen, de a storm az egy teljesen különálló termék. Ha a hadoop-ról beszélünk, az bizony nem fog realtime adatot feldolgozni neked sehogy. A storm pedig egy teljesen különálló framework (az elején pedig teljesen saját resource manager-el dolgozott), majd integrálták resource manager-nek a yarn-t, pont (aminek a használata egyébként nem is kötelező, mert futhat teljesen külön)


// Happy debugging, suckers
#define true (rand() > 10)

"majd integrálták resource manager-nek a yarn-t" Tehat ha van egy Hadoop clustered, akkor tudod hasznalni a Stormot real time adat feldolgozasra vagy sem?

-
Go konkurencia kezelés gyorstalpaló

Ha nincs hadoop clustered, a stormot akkor is tudod real-time adat feldolgozasra hasznalni.


// Happy debugging, suckers
#define true (rand() > 10)

a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'

-
Go konkurencia kezelés gyorstalpaló

b! :D


// Happy debugging, suckers
#define true (rand() > 10)

ha van egy hadoop clustered, akkor meg tudod csinalni ket gep munkajat szaz gepen :)))

--
NetBSD - Simplicity is prerequisite for reliability

vagy nem :DDD


// Happy debugging, suckers
#define true (rand() > 10)

+1, szerintem is a legjobb megoldas, hogy kevesebb userre meretezed, es kiadod az MVP-t hamarabb, aztan ha elkezd felfutni, akkor ujrairod megfeleloen skalazodora a jelenlegi tapasztalatok alapjan.

Ha stabil kell, akkor C, C++. Mezei socketek, semmi extra. Persze jól kitesztelve, segfault mentesen.
JAVA-ban se nehéz megírni, de ahhoz nem árt ha van vasad :D
NodeJs jó cucc, de nem biztos, hogy használnám erre, persze ki is zártad.

Ami viszont lényeg:
Szerintem nem feltétlenül maga a program számít, nem nagy dolog egy chates socket szervert összedobni.
Egy darab program tuti nem vinne stabilan több millió online usert. A program fölé kell tervezni egy rendszert ami foglalkozik az erőforrásokkal, és szálakat hoz létre, párhuzamos futtatásra. Sőt, még a több szerveres megoldás se lenne rossz szerintem, akár virtuális gépeken is. Tehát több párhuzamosan futó szerver, azon belül pedig párhuzamosan futó szálak.
Érdemes konfigurálhatóvá tenni az egészet, így a konfig átírásával tudod méretezni az egészet. Attól függően, hogy mekkora terhelésre számítasz.
A megvalósítás részletkérdés: Pl a kliens dönti el, hogy melyik szerverhez csatlakozzon, azon belül melyik szál portjához (terheléstől függően), vagy a kliens csak egy terheléselosztó szerverhez csatlakozik és az a belső hálón eldönti, hogy melyik alszerverhez, azon belül melyik szálhoz dobja be a klienst. Kívülről ez rejtve marad. De ez már megvalósítás kérdése.

Most olvasom közben, hogy DB-t is kérdezel. Valaki írta a Redis-t. Az nem rossz megoldás, pl szobák tárolására. A kommenteket nem tárolnám benne. Ha kell archiválás, akkor már egy sql-es "lassú" db is megfelel (persze ott se rossz ha van valami rotálás, nem biztos, hogy van értelme letárolni egy kommentet több évre, sőt...)

A java továbbra is annyira iszonyú erőforrászabáló, mint ami volt 5+ éve?
Vagy voltak esetleg - nagyon - pozitív változások?

Miért lenne az? A világ HFT rendszereinek nagyrésze Java. Ha a lassú desktop appokra gondolsz, az tök más tészta. Szerveren a Java rendkívül gyors tud lenni, miért is lenne lassú? GC stratégiától függően relatíve sok RAM kellhet neki, cserébe kb. 0 költségű memóriafoglalást kapsz, meg lényegében egy slidert a throughput/latency között. (A G1 kollektor egész szépen kezeli a sok memóriát, tehát nem probléma akár a terabájtos heap sem.)

----------------------
while (!sleep) sheep++;

soha nem is volt az

--
NetBSD - Simplicity is prerequisite for reliability

Valszeg a Java is olyan mint a php. Szakavatott kezekben dorombol, de kóklerek kezében halálos fegyver. Ez utóbbi a gyakoribb szerintem.
Van egy rendszerünk amit külsős csapat fejleszt. Weboldal mögötti backend. Java-ban. Ocsmány szar. Látogató nincs rajta sok egyáltalán, de volt amikor bezabált 10-15GB memóriát. Valamit szarul csináltak meg. (valami jetty-s cucc pörög alatta).
Manapság a fejlesztők zöme nem képes optimalizálni, mert sokuk alá odateszik a vasat. Nálunk legalábbis ez van.

Ugyanez megy a játékfejlesztésben is. Elég megnézni, 20 évvel ezelőtt oda kellett figyelni minden kB memóriára, ma már aszondják a játékfejlesztő cégek, hogy vegyél jobb VGA-t.

Tegyük hozzá, hogy a szoftverek jól el is rejtik a mai kódmunkás elől az optimalizálás lehetőségét. A keretrendszerek ellenőrizhetetlen dolgokat, kódokat csapnak hozzá a késztermékhez, stb. Azután jött a gyors fejlesztés, mint követelmény. Nincs is idő alapos optimalizálásra, rövid határidőket szabnak a megrendelők, így a fejlesztők olyat szállítanak, amit ennyi idő alatt létre lehet hozni és hozzá teszik: vegyél nagyobb vasat!

Igy van. A fejlesztő meg hiába sír, hogy legalább teszteket csináljunk, meg mérjünk, meg akármi, nem, az nem fontos. A csillió+1-edik, senki által nem használt feature,
az a fontos.

A Java pont olyan erőforrás zabáló, mint 5 vagy 10 éve volt... viszont nagyságrendekkel jobb, mint 20 (!) éve. Imádom, amikor az emberek ennyire a régmúltban élnek.

Ugyanolyan mint 5 éve. Szerver oldalon, warmup után, normális kezek között hasít.

--
arch,debian,retropie,osmc,android,windows

+1
Gyuszk-al karöltve maszíroztunk olyan rendszert, ami backend oldalon Java és óriási terheléseket visz el mind a mai napig. (mondom ezt úgy hogy én egyébként be vagyok oltva java ellen :D)
Nem rossz az, csak hozzáértő kezek kellenek ahogy ő is mondta ;)


// Happy debugging, suckers
#define true (rand() > 10)

A WhatsApp-ot Erlang-alapokon írták, pár száz millió usert elvitt. A Slack Java. FB messenger Erlang/PHP/C++.

----------------------
while (!sleep) sheep++;

En a helyedben a Telegram [ https://en.m.wikipedia.org/wiki/Telegram_(messaging_service) ] fejlesztőire dobnék egy e-mailt pár kulcskérdéssel.

100+ millió usert szolgál ki és a leggyorsabb+legstabilabb chat szoftver amit életemben használtam.

+1

+1

Scala + Akka - backend
React + Redux/Relay - frontend
Kotlin / ReactNative + Redux/Relay / ?Flutter? (valszeg meg nem eleg kiforrott) - mobil

Ha React/ReactNative, akkor Material UI look & feelnek.

Kafka jol hangzik messagingnek.

+1 a Scala-Akka kombóra, vagy esetleg erlang/elixir (zseniális dolog)

Adatbázisra a voltdb-t hallom emlegetni hasonló kontextusban, meglesném.

Van valamelyikkel konkrét tapasztalatod? Erlang érdekelne.

Odalent mono gui meg php. Meg indítani kell egy websocket
------------------------
Jézus reset téged

MongoDB erre nem a legjobb választás.
Meg a PHP sem.
És a kliens oldalon ugyan csak egy websocket connection, de a server poolban már pár millió.

subs

Sajnos a tobb millio user mint olyan nem mond semmit. Ha tobb millio user van benne, de alig beszelgetnek az tok mas terheles lesz mint tobb millio user aki mint aki megorult nyomkodja a billenytuket. Azt is erdemes elmondani, hogy ha ez nem egy mar meglevo chat szoftver csereje, akkor erdemes megfontolni, hogy nem ekkora meretekben kell indulni. Sokszor az uzleti vezetok szeretnek nagyot almodni, de egy tobb millio userre felkeszitett chat teljesen maskepp epul fel mint egy par tizezer useres es sokkal sokkal tobb idobe es penzbe kerul.

Most hogy ezt tisztazzuk, nezzuk a gyakorlati oldalat. Nagyobb chat szolgaltatok kozul joparan XMPP-re (Jabberre) epitenek. Ehhez temerdek library es szoftver van, szoval nem kell mindent ujra kitalalni. Raadasul letezik horizontalisan skalazodo szerver oldali technologia hozza. A hatulutoje viszont az, hogy nagyon komplex a technologia, es nem fogod meguszni az extensionok implementalasat. Az XMPP nehany problemajarol a ChatSecure alkotoja irt reszletesebben es erdemes a blogban visszatekerni. Egy multbeli hasonlo projektekbol elmondhato az, hogy a kovetkezok biztosan fognak nemi fejfajast okozni:

- XMPP-ben a chatek perzisztens tarolasa a kliens feladata. (XEP-0136)
- XMPP-ben (tudtommal) a chatek amolyan session-stilusban mennek, klienstol fuggoen az uzenetek nem kerulnek kezbesitesre minden eszkozre.
- Push notificationok a kliensekre.

Persze azt is csinalhatod, hogy nullarol elkezdesz irni egy chat megoldast, ez esetben meg kell oldanod mindazt amit az XMPP mar sikeresen megugrott, pl. uzenetek routolasa, presence uzenetek, stb stb stb.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

+1, ilyet biztos nem írnék nulláról.

Én céltól függően még azt is megnézném, hogy a feladat nem oldható e meg egy létező szolgáltatás tetején. Gyakorlatilag minden nagy cégnek van már chat-je. És minden nagy cég ezen pörög (MS, Apple, Google, Facebook stb.). Ha nem kifejezetten chat-tel foglalkoztok, akkor egyszerűbb lehet egy Google Hangouts/Facebook Messenger/Skype (ha onsite kell tartani az adatokat Microsoft Lync) tetejére integrálni azt, ami esetleg hiányzik.
--
http://naszta.hu

+1 pl. salesforce social media connector, összefogja az összes elterjedt platform chat-jét és megkapod std api-ban, rá tudod rakni a saját okosságokat.

Koszi mindenkinek, 3 dolog merult fel, amiknel tovabbi reszletekre kerdeznek:

1. Funkcionalis nyelvek: scala, erlang. Tenyleg "megkerulhetetlenek" ezen a mereten? Van valami amit abban meg tudnek oldani bennuk es C++-ban nem es jo esellyel szukseges?

2. DB - tobb NoSQL felmerult, es ertheto is, hogy klasszikus SQL itt nem fog mukodni. Egyik szempont ugye, hogy ekkora meretben foreign key-ek felejtosek, masreszt jobb, ha a db ugy van tervezve, hogy "abbol torolni nem nagyon fognak" (ez utobbi mondjuk pont igaz a Facebook mysql forkjara is). MySQL-nel es PostgreSQL-nel meg csak olyan replikaciot lattam, ahol egyvalami tudott irni, tobbvalami read only slave volt. A sokat emlegetett "horizontalis skalazas" tobb gepre szepen hangzik, hogy tobb gep tudjon irni, de felmerult bennem tobb reszletkerdes:
-mig gepen belul a tobb CPU mag elintez egy atomic/volatile valtozot par microsec alatt, egy modern SSD-re irni se olyan veszes mar flush-kor, addig a masik gep fele ahova "horizontalis skalazok" megy egy (jo par) TCP csomag, meg tegyuk fel 2 msec latency es 1 Gigabit. Van valami szamitas arra egy letezo NoSQL db mukodoeset figyelembe veve, hogy mi az az adatbazis meret es irasi gyakorisag, ahol mar ez megeri (vagy ahol mar csak ez mukodik)?
-masik kozelito megoldas amire gondoltam: chat resztvevoibol hash es azalapjan annyis maradek ahany gep van, a db-knek nem is kell tudniuk egymasrol, kiveve amikor "uj gepeket nyitok" es sync van (viszont lehet ez a sync nem lesz eleg gyors/sync alatt problemas lesz hasznalni)

3. XMPP, WSS eleg jo lesz nekem?

Nincs olyasmi, amit funkcionális nyelvekben meg lehet oldani, de C++-ban nem (és vice versa). A kérdés inkább az, hogy milyen mintázatokat "sugall" a nyelv (vagy framework).

Példa: Clojure alatt lényegében minden érték alapból immutable, ami nem, azt tranzakcionalis szemantikaval változtathatod, lock nem létezik a nyelvben (egyszerűsítek). Ennek egész brutális előnyei/hatásai vannak -- a versenyhelyzetek, adatkorrupciók kb. eltűnnek, helyettük inkább a ritkán előforduló, magas kontencio esetén létrejövő starvation, etc. a probléma. Namost ha ez szimpatikus, akkor vagy funkcionális nyelvet használsz, vagy C++-ban csinálod ugyanezt, de úgy sokkal több melót kell belefektetni.

Egyáltalán nem fekete-feher a probléma. Chat esetén (erősen párhuzamos események, információk passzolgatasa rengeteg logikai actor között) én beprobalnam a Scala/Play kombót, vagy Clojure-t, vagy az Erlangot.

----------------------
while (!sleep) sheep++;

A Clojure lenne az utolso, amihez nyulnek (Scala-t Erlangot nem zarnam ki viszont).

Nyilván azt használsz, ami jól esik, csak azt akartam mondani, hogy bármiben lehet bármilyen stílusban programozni (csak nem feltétlenül érdemes).

----------------------
while (!sleep) sheep++;

Idézet:
3. XMPP, WSS eleg jo lesz nekem?

Mi a feature set amit meg kell valositani? Sima szoveges uzenetek? Vagy legyen benne Facebook-stilusban embedded media? Lehet esetleg formazni az uzenetek? Kell-e tarolni az uzeneteket a kliensek kivetelevel? Kell-e end-to-end titkositas? Kell-e tudni csatolmanyt kuldeni / es permanensen tarolni? Kell-e biztonsagos letolto link amit nem lehet megosztani a csatolmanyokhoz? Honnan tudod hogy tenyleg userek millioi lesznek? A userek millioi hany uzenetet fognak kuldeni az elozetes tesztek szerint? Hogyan azonositod a usereket? Lesz-e egynel tobb kliens egy usernel? Milyen kliens lesz? Webes vagy alkalmazas? Milyen technologiakhoz van szakertelem a cegnel? Es meg millio kerdes felmerul bennem.

Lehet hogy annyira specialis kovetelmenyeid lesznek, hogy tobb energia azokat XMPP-ben megvalositani, de az is lehet, hogy gyk. egy az egyben az kell neked amit az XMPP vagy az IRC mar tud. Szoval ennel sokkal tobb info kell, mert igy egy zsak tanacsot fogsz kapni es korant sem biztos hogy a Te esetedre alkalmazhato lesz barmelyik is.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Google Firebase. Automatikusan skálázódik, igaz 1 millió usernél már biztos nem két forint. Cserébe nem kell csak a klienst fejleszteni.

A kliens fejlesztese az a legkevesebb. Itt a szerver oldal az pont, ahol eros engineering szukseges.

Ha jól értem, spyff éppen arra utalt, hogy a szerver ekkor a Google gondja, neked csak a klienssel kell törődni.
Én nem értek ilyen rendszerekhez, de ha nekem kellene csinálni, biztos firebase-zel próbálkoznék és nem állnék neki bármilyen nyelvben programozni szervert, iOS, Android, web klienset. Persze akkor, ha valamiért nem kell ragaszkodni a saját szerverhez.

--
Soli Deo Gloria

Igen, erre érettem. Egy délután alatt össze raktam vele egy kis chat progit. A firebase rész alig pár sor benne. Ami előny, hogy nem kell protokollt programozni, alapból titkosított TLS csatornán a kliens-szerver kommunikáció (nyilván az üzenetek ezen felül még titkosíthatók, p2p titkosításhoz is).
Sebességről annyit, hogy egy tabletről 10 milliszekundumonként küldtem 1000 bájtos üzeneteket. Egy sem veszett el, a másik tablet meg egy emulátor mindet megkapta, átlagos válaszidő kb. 200ms, de a jitter sem volt több 30ms-nél. A kapcsolat megszakadást, újraépítést szépen megoldja a háttérben, addig maga cacheli az elküldött üzeneteket és ha újra feláll a kapcsolat, burst-ben felküldi. Simán tudtam chat közben Wifi-LTE között váltogatni, nem halt szét - annak ellenére, hogy egy sor hálózatkezelés kódot nem írtam.

Lehet integrálni cloud functionnel is (AWS lambda Google megfelelője. Úgy mondjuk picit drágább a dolog, meg növel a válaszidőn is). Ez is automatikusan skálázódik, használható pl. özenetek felhős feldolgozására.

-

Én egy MQ-t raknék alá, ActiveMQ, RabbitMQ. A nyelv az mindegy onnantól, az csak a fedőszerv.

Jabbert is lehet, van erlangos (ejabberd). Az erlang otp lib aokat tud az ilyenekben segíteni amúgy.

De volt pythonban is HA lib, twisted volt tán a neve.

Neki lehet állni baltával C-ben csak minek.

AMQP? Lassú és halott protokoll. NATS, Kafka, ezek lehetnek érdekesek elosztott time-series adatokra.

----------------------
while (!sleep) sheep++;

https://content.pivotal.io/rabbitmq/understanding-when-to-use-rabbitmq-or-apache-kafka

Itt ranezve a kewt kepre nekem jobban tetszett a RabbitMQ mint a Kafka, utobbihoz kell egy "primary broker"

Próbáld ki őket. A Kafka skalazodasa konkrétan két nagyságrenddel jobb, mint pl a RabbitMQ-e (ez egy nagyon általános kijelentés, de nézz utána, próbáld mi). A Kafka bizonyítottan képes egyszerre 10-100 terabájtos elosztott adatbázisként és nagyon gyors queue-kent működni, a Rabbit egyiket sem tudja.
A Kafka esetében sem kell SPOF.

----------------------
while (!sleep) sheep++;

Akármi. Én csak azt tudom, hogy a publish-subscribe nagyon jól modellezi az összes ilyet, amik otthagyták a jabbert (XMPP-t), azok mind valami MQ megoldás felé mentek, ahol minden beszélgetés egy queue.

Egyetemen meg azt tanultam, hogy ne akarjak magamnak MQ-t írni, mert játszásiból nagyon könnyű (írtam is), de skálázóra írni baromi nehéz, vegyek le egyet a polcról oszt szevasz. Olyan mint az adatbázis szerver üzleti szoftvernél, azt se írsz mert minek.

Míg a jabber megkülönböztetett presence, sima direkt meg chatszoba-üzeneteket, és csak az utóbbi ment PubSub alapon, addig az MSN meg az IRC protokoljai a fentit csinálták (csatornanyitás mindenre), és hát mindenhol szép sorban kib.szkodták az XMPP backendeket egy idő után - FB, Google, WhatsApp, ezek mind XMPP-kompatibilisek voltak régen.

Szóval szerintem a backend fordítson le mindent MQ-ra, és legyen kb. kérés- (kérész :) életű benne minden processz. Innentől kezdve meg akár (nemröhög) PHP is lehet.

Azért ezt olvasd el, mielőtt bármit is választasz:
http://www.kegel.com/c10k.html

Koszi, fentebb sj is emlitette, mar akkor elkezdtem utananezni es olvasni. Hasznos

+sok
nagyon tanulsagos iras. anno azt hittem irok 10 perc alatt egy egyszeru (1db static oldalt kiszolgalo) webservert, aztan hamar kiderult, hogy nem is olyan egyszeru :)

nalam 4000-nel allt meg a tudomany(nem http szerver). De ez nagyon regi emlek, hogy mi fogyott epp el. Egyszerubb volt a userbaset korlatozni, hogy 4-5k alatt legyen.
Azert 4k nyitott tcp socket nem piskota.

Mondjuk azota eltelt par ev...

Szerintem a kapcsolatok kezelesere van kesz megoldas manapsag. En biztos irodalomkutatassal kezdenem, mielott valamelyik kulfoldi kolleganak atpasszolnam:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Hasonlóan érdekes Avi Kivity (korábban KVM, OSv fűződik a nevéhez) előadása a ScyllaDB-ről: https://www.infoq.com/presentations/scylladb

Maga a ScyllaDB egy dron-in kompatibilis Cassandra klón csak nagyságrendekkel gyorsabb - az előadásban arról beszélnek, hogy milyen architektúrával érték ezt el.

Köszi, ezt nem ismertem, de nagyon jónak tűnik!

A drop-in kompatibilitás akkor igaz, ha 2.2 a Cassandra verziója semmi extra feature nincs használatban, aminek van Java érintettsége (Java trigger, user defined function, satöbbi) és a "nagyságrendekkel gyorsabb" se jön ki egyértelműen, csak erős peremfeltételekkel. Az ötlet ugye az volt, hogy a C++ az mennyivel gyorsabb, mint a Java, csak a valóság az, hogy nem lett gyorsabb... sőt, nagyobb terheléseknél a ScyllaDB minden előjel nélkül összeomlik, a Cassandra csak belassul.

Ott van az irc mint backend, csak a frontendet kell megirni. Brutalis méretű hálózatok vannak rajta, jol skalazodik. Futtathatsz, sajat szervereket. Logolni pedig, ha igeny van ra akkor tudsz a deamonokon keresztul.

---...---
TLoF

IRC-t akartam én is mondani. '99-ben több milliós felhasználószám volt IRC-n. Belegondolva hogy milyen vasak és hálózatok voltak akkoriban, mai infrastruktúrán nagyon szépen kell hogy muzsikáljon. Vagy XMPP?

Utána olvasva: IRC egyidejű aktív user rekordok, 6m 2001-ben, 10m 2003-ban.

Kisgatyaban, fulbevaloval, szovegszerkesztoben. Nagyjabol.

http://karikasostor.hu - Az autentikus zajforrás.

Hehe, én is erre gondoltam elsőre :-)

Csak én Donald Kacsának öltözve csinálnám: http://szleng.blog.hu/2009/02/14/donaldkacsazik

CUDA :)

[Feliratkozás]

+1

+1

+1


Sic Transit Gloria Mundi

Ami kimaradt, hogyha a backendet sikerult jól megcsinalni, akkor a kliensek csatlakoztatásat meg lehet csinalni go daemonokkal. Jol programozható, eléggé hülye biztos és a skalazodik. Tud web socketet, es minden mai divatos mq megoldást.

---...---
TLoF

ha mar nodejs:
egy 2015-os cikk 600k kapcsolat kiszolgalasara websocket es nodejs alapon:))

https://blog.jayway.com/2015/04/13/600k-concurrent-websocket-connections-on-aws-using-node-js/

Szerintem irdd meg random nyelven, es amikor elered a 100k felhasznalot akkor vegyel fel egy programozot;)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Troll: összehívnám az összes potenciális felhasználót egy konferenciaterembe, és azt mondanám nekik: Jocó, Fecó, ti ketten telefonon tartsátok a kapcsolatot egymással.

https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_daemons

Az n+1 megírása nekem olyannak tűnik mint a forró víz feltalálása... nem lenne egyszerűbb egy meglévő daemon-t választani és szépen megírni hozzá a klienseket??

+1

Nem biztos hogy ezek közül bármelyik is alkalmas több millió embert kiszolgálni / skálázódni / stb. A legtöbbje valószínűleg 90-es és 2000-es évekből maradt fosszília, ami az IRC párszáz, maximum párezer használóját kiszolgálja. De nem néztem át tüzetesen. Mindenképpen valamilyen nagyon aktuális cuccot vetnék be inkább.

--
arch,debian,retropie,osmc,android,windows

Mint fosszília annyit tennék ehhez hozzá, hogy régen igen komoly IRC hálózatok voltak igen kemény forgalommal és még ma is bőven sokan használják. Megint az a titka a dolognak, hogy ha jól összerakják, a skálázódást szem előtt tartva, akkor menni fog az. Az megint más kérdés, hogy az IRC főleg a szoba/közösség alapú szerveződésekre ment rá és nem a person-to-person csapásirányra, ahol néha behívsz röbb résztvevőt. Egyébként ez utóbbira pedig ott a Jabber. :)

(Én ugyan még sosem cseteltem, de azért érdekelne, hogyan veszett ki az emberekből (legalábbis a többségből) az IRC használatának képessége az elmúlt húsz évben. (Egyébként pl. a prog.hu is tele van különféle ifjú titánok 'webes chat-et szeretnék' topikjaival.))

(tröll)
Ha azt kérdeznéd, mit használnék... a helyes választás természetesen az Outlaw Techno Psychobitch, rövidítve: OTP.

A kétkedőknek itt egy tudományos kisfilm:
https://www.youtube.com/watch?v=rRbY3TMUcgQ
(/tröll)

Teljesen felesleges komment: https://www.youtube.com/watch?v=9Z9h8lGZsX8

haha,ez jó volt

A kis melegítőmben pl a gép előtt ülve.

Én is a meglévő technikákban gondolkoznék, valami HTTP(S) feletti protokollt használva, ami jó sansszal átmegy proxy-n, céges tűzfalon (ha csak direkt a szervereidet nem blokkolják), többszörösen NAT-olt mobilneten ésatöbbi. Az se baj, ha már vannak hozzá kész kliensek, csak a szolgáltatást kell beizzítanod, saját szerveren/felhőben. Nem vagyok jártas chat-ben, de tuti van ilyesmi.

golang

Ja, a tippem: használj Mátrix/Riot párost, és kész.

----------------------
while (!sleep) sheep++;

+1
Sőt, kicsit jobban is meg lehetett volna nyomni azt a matrix.org -ot. A "How does it work" résznél van pár szép leírás ami ötleteket adhat a tervezésben. Példák és próbák is szép számmal beszerezhetőek mind kliens mind kiszolgáló oldalra.

Amúgy ebből az apropóból ismét ránéztem a Prism-break -re. ( https://prism-break.org/en/all/#instant-messaging )

Illetve anno innen kiindulva pár hónapja a Wire tetszett még meg ( http://alternativeto.net/software/wire/?license=opensource ). Bár volt rá nyilatkozat hogy megnyitják a server oldalt is, de úgy tűnik inkább a fizetős szolgáltatásokat próbálták bevezetni azóta.
A github oldalukon azért van pár ábra, hogy ők kb. hogyan, merre-meddig. ( https://github.com/wireapp/wire-server )

Ez még nem biztos hogy jó.

Amúgy meg a kérdezőnek: Hajrá! Szívesen látnék már egy teljesen java mentes megoldást egy ilyen volumenű dologra.

--
RudyD

Szerintem: elindulnék a koncepcióval, hogy egyáltalán működik-e a piacon és ha dől a pénz az egymillió potenciális felhasználó miatt, akkor vennék kilóra pár sovány matematikust és egy-két fejlesztőt és ők majd megírják skálázhatóra. Persze, lehet álmodozni arról, hogy majd mekkora terhelés lesz és évekig lehet fejleszteni titokban a Halálcsillagot, csak ugye az lesz ebből, hogy valami közbejön és a szellőzőnyíláson át felrobbantják az egészet. A hídon akkor menj át, ha odaértél.

+1

És ha már ott tart, hogy dől a lé? Csak épp a kilóra vett informatikus nem tudja, hogyan kellene, és ezért kérdezik a HUP-ot :).

Ez egy teljesen életszerű eset... :D

Ha ez az eset van, akkor lenne kicsit pontosabb requirement ;) Latszolag annyi a specko, hogy "Miben irnal tobbmillio useres chatet".

-
Go konkurencia kezelés gyorstalpaló

Ezzel a megközelítéssel van egy olyan probléma, hogy ha bejön a biznic, akkor mindenki ki akarja próbálni _azonnal_. Amikor berobban a népszerűség-bomba, akkor már késő reagálni, nincs idő. Na most, ha ekkor automatikusan aláprovisioningolsz pár virtuális szervert és minden fennakadás nélkül alacsony latency-vel működik, akkor az emberek rákapnak.

Ha meg belassul, akkor megállapítják, hogy ez szar, és a brandnek annyi.

Így járt az iWiw: amikor megugrott a látogatottság belassult, és képtelenek voltak begyorsulni. Még újra is írták Java-ban, hogy gyorsabb legyen (LOL). Ha nem lassult volna be, még ma is fél Magyarország iWiw-ezne és nem Facebookozna :-).

Bár biztos vagyok benne hogy az 1.4-es időkből származó mémnek igazak voltak, de így 1.9 fele aki lassú kódot ír Java-ban az szimplán nem érti mit csinál ^^

> még ma is fél Magyarország iWiw-ezne és nem Facebookozna

Nem értek egyet, amikor megtörtént a váltás a facebook azon kívül hogy sokkal szebb volt, sokkal hatékonyabban lehetett rajta csajozni, ami az egész lényege. Böködés és a többi. A Google Plus masszívan jobb szolgáltatás volt a facebooknál amikor megjelent, de a nőket nem sikerül behúzniuk így nem nagyon érdekelt senkit a mérnökökön kívül.

"Ezzel a megközelítéssel van egy olyan probléma, hogy ha bejön a biznic, akkor mindenki ki akarja próbálni _azonnal_."

Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni...

"Na most, ha ekkor automatikusan aláprovisioningolsz pár virtuális szervert és minden fennakadás nélkül alacsony latency-vel működik, akkor az emberek rákapnak."

Aha... hány ilyet csináltál már? :)

"Így járt az iWiw: amikor megugrott a látogatottság belassult, és képtelenek voltak begyorsulni."

Ott alapvetően pénzhiány volt éveken át, mert nem tudták a forgalmat pénzre váltani.

"Még újra is írták Java-ban, hogy gyorsabb legyen (LOL)."

LOL persze... gondolom fogalmad nincs, hogy mi volt Java és miért volt Java és mi nem volt Java. És arról sincs fogalmad, hogy miért használnak Java-t ilyen célokra.

"Ha nem lassult volna be, még ma is fél Magyarország iWiw-ezne és nem Facebookozna :-)."

Nem a sebességével volt gond, hanem azzal, hogy nem nemzetközi porondon elvérzett a magyar piac meg kicsi.

„Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni...”
BKK elektronikus jegyrendszer?

a kávém! :-D
--
blogom

Köszönöm, ez jól esett.

:-D

nap kommentje :D

"Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni..."

nem tud, mert azok definíció szerint nem futottak fel ;)

(rejtett sub)

"Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni..."

Pokemon Go sokáig szenvedett például :). Mondjuk nem teljesen a felvetésre válasz, mert ezt azért rendesen megtervezték, csak elszámolták. Ahogy pl. sok magyar közigazgatási rendszerrel is előfordul. Egyik se úgy indul, hogy ezt most direkt szarul írjuk meg, csak így sikerül.

"Nem a sebességével volt gond, hanem azzal, hogy nem nemzetközi porondon elvérzett a magyar piac meg kicsi."

Na ezt sose értettem. Egy időben a WIW beszélt angolul. Pont azért lett IWIW, mert international. Hívtam is volna rá külföldi ismerősöket. Aztán egyszer csak eltűnt az angol nyelv. Lehet, hogy a jó értelemben vett felrobbanástól féltek, másként nem nagyon tudom elképzelni, miért butították le direkt.

"Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni..." egy rakás "slashdotted" oldal van. Hirtelen jönnek a látogatók, aztán nincsenek kiszolgálva. Instant bukó, az emberek 99%-a másodszor nem kattint rá. Hallani nem hallunk róluk, mert ugye nem lesznek híresek.

"Aha... hány ilyet csináltál már? :)" nem csináltam, de ha arra számítanék, hogy fel fog futni, akkor így kellene tervezni. Máskülönben bukó lesz a felfutáskor. Ha dőlnek az emberek ki kell őket szolgálni, mese nincs.

Konkrétan a Facebook pont azt csinálta jól, hogy skálázódott a felhasználókkal, amióta először láttam sose lassult be.

Nem a Java a LOL, hanem az, hogy majd attól önmagában gyors lesz. Ha nem sikerül a skálzódás léptékét megjavítani, akkor tökmindegy miben van, lassú lesz.

Oké, az talán túlzás, hogy ma is iWiw-eznénk, de egyérteltelműen volt egy időszak, hogy mindenki be akart lépni, és épp akkor baromira belassult. Én azt tippeltem akkor, hogy nem tud skálázódni. Mert ha tudott volna, akkor nem lettek volna akkora marhák, hogy ne toljanak alá plusz szervereket. A T vette meg, ha jól emlékszem, nem hiszem, hogy pénzhiány lett volna. Ha nem lassult volna be, akkor tuti, hogy növekedett volna még egy darabig.

(Kivéve, ha direkt azért vette meg a T, hogy kivéreztesse - volt már erre is példa a világtörténelemben.)

+1

"Hirtelen jönnek a látogatók, aztán nincsenek kiszolgálva. Instant bukó, az emberek 99%-a másodszor nem kattint rá. Hallani nem hallunk róluk, mert ugye nem lesznek híresek."

Na, mint például?

"Konkrétan a Facebook pont azt csinálta jól, hogy skálázódott a felhasználókkal, amióta először láttam sose lassult be."

Konkrétan a Facebook pont szar volt eleinte, csak annyira kicsi volt, hogy senkit nem érdekelt, hogy lassú... simán elindultak puszta MySQL és PHP alapokon és mire felfutott 3-4 év alatt, addigra már rég megoldották a skálázódási problémákat... :)

"Nem a Java a LOL, hanem az, hogy majd attól önmagában gyors lesz"

Pedig sokat segít...

"A T vette meg, ha jól emlékszem, nem hiszem, hogy pénzhiány lett volna. Ha nem lassult volna be, akkor tuti, hogy növekedett volna még egy darabig."

Nem volt lassú... én a kétezer-valahányadik felhasználója voltam, láttam a kezdetek óta, nem volt lassú. Inkább szimplán szar és feature szegény volt, főleg, miután telenyomták borzasztóan zavaró reklámokkal.

Hirtelen jönnek a látogatók, aztán nincsenek kiszolgálva. Instant bukó, az emberek 99%-a másodszor nem kattint rá. Hallani nem hallunk róluk, mert ugye nem lesznek híresek.

Így van, az emberek nagyon érzékenyek a késleltetésre (latency). Van is erről egy jó írás.

"Latency matters. Amazon found every 100ms of latency cost them 1% in sales. Google found an extra .5 seconds in search page generation time dropped traffic by 20%. A broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition."

> Konkrétan a Facebook pont azt csinálta jól, hogy skálázódott a felhasználókkal, amióta először láttam sose lassult be.

http://index.hu/tech/2017/08/26/akadozik_a_facebook/

:-D

"Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni..."

Ello

Ello? Hol van itt a hirtelen felfutás? :)

Vegul sehol, de 20 ismerosom is vegul kapott invite-ot es ott hagyta mert lassu volt es be se toltott

Az Ello (kozossegi oldal) meg jobb pelda mint az iwiw: a marketingesek elertek mindenkit, csillagos otosre vizsgaztak, a dev team meg egyesre a lassu valaszidokkel.

Szerintem azért meg kéne nézni több faktort is.
Az fb is elitista meghívásos alapú közösségként kezdte, lehet hogy ez is volt az egyik nagy vonzereje.
A g is mikor elindította a levelezését, az is csak meghívóval ment.
Gyakorlatilag megvolt a megfelelő folyamat és lehetőségük volt csak annyi terhelést beengedni ami még nem vágta haza az egész üzletet.

Valahol mindkettőt a gondolkodás nélküli kapzsiság pörgette túl a peremen.
Bár kétségkívül nem a fejlesztőit akarom védeni, de ha egy márkanév bedöglik akkor ott máshol is lehet keresni a valódi felelősöket.

A fejlesztést, kódolást, marketinget és az üzemeltetést egyensúlyban tartani sem lehetetlen, csak a megfelelő gondolkodással és módszerekkel és visszacsatolással kell megtenni.
--
RudyD

VueJS kliensen Akka szerveren MongoDB üzenet tárolásra. Mobil kliensek natívan. Kommunikáció WebSocket ofc.

Tutoriallal már meg is írták Neked! :-)

That’s it. Were done. Now we have a, very simple, but scalable, fault-tolerant, event-driven, persistent chat server that can without problem serve a million concurrent users on a regular workstation.

Akka, vagy más actor rendszer helyett valamely message broker (Kafka, *MQ) rendszer használata lehet még egy jó és könnyen járható megoldás.

Erlangban. Voltmar?

(Egyebkent minek ujra feltalalni a spanyolviaszt, ha nem muszaj, lasd pl. https://www.ejabberd.im, de nyilvan ezeket a koroket mar lefutottad, csak ugy eszembe jutott :))

Multithread?? Hát egy több millió user-es chat esetén a multi thread lenne az utolsó dolog amit kipróbálnék. Mindenképp async io-ban gondolkoznék. IPC-re redis vagy zqm vagy rabbitmq.

Prototyping python+asyncio vagy python+tornadoweb, és ha működik akkor átírni natív szervert c++ -ba.

Az is kérdés, hogy ez "csak" egy chat, vagy lesz benne szociális háló, vagy valami ami hálósan összeköti ezt a sok embert? Mert ha lesz, akkor még egy adatbázis kell, ami elosztott és hálósan lekérdezhető.

Multithread? Mi baj a multithread-el? Ráadásként a multithread és az async io egyáltalán nem zárja ki egymást, sőt


// Happy debugging, suckers
#define true (rand() > 10)

Az, hogy helyesen így írják: multithreaddel.
Egy vonal nem helyettesítheti a toldalék kezdőbetűjét, én ilyen szabályt nem ismerek.

--

nTOMasz
"The hardest thing in this world is to live in it!"

Cserébe az esetek nagy többségében olvashatóbb, mint az akadémia által favorizált mód.

Esetleg azoknak, akik a helytelenhez vannak szokva. A többségnek nem.
--
♙♘♗♖♕♔

Nem tudok a többség nevében nyilatkozni, én azért szoktam így írni, mert véleményem szerint az összes, magyar fonetikába rosszul illeszkedő külföldi szó katasztrofálisan szarul olvasható a helyes írásmóddal, főleg, ha egyébként fogalmam sincs, hogy kell kiejteni, hello franciák (és az összes jövevény szavuk az angolba :). Bizonyára köze van ahhoz, hogy képolvasok, mivel azt tanították (és ezzel vagyunk még egy páran). Szóval ha bizonytalan vagyok, én bizony kiteszem, és nem nagyon érdekel, hogy a nagykönyv szerint az úgy nem helyes. A thread végére nem tenném ki, de egyáltalán nem zavar, hogy ott van.

Azt hiszem félreértettelek. A kötőjeles írásmód engem sem zavar, és szerintem is olvashatóbb. Ami viszont igen, az a toldalékok megcsonkított használata. Olyan ugyanis nincs, hogy "-al", "-el". Szóval ha kötőjelesen írjuk, akkor "multithread-del".
--
♙♘♗♖♕♔

mivel a kötőjellel kvázi feladtuk, hogy rendesen hasonuljon a magyar írásba, ezért szerintem ez már ízlés kérdése. Speciel én itt inkább fölöslegesnek érzem dét a -del-ben ( :) ) és nem zavar a hiánya, amikor meg a szó végi hangzó egyébként sem egyértelmű, vagy azért, mert az olvasó műveletlen, vagy azért, mert van neki egy közbeszédben rosszul rögzült formája (sevrolé, sevrolet pl), vagy mert épp félúton van a szó a magyar nyelvbe épülésbe, és változik a kiejtése, akkor még jobb is lehagyni, aztán mindenki azt olvas bele, ami az ő fülét nem zavarja. A magas/mély még úgy is lehet szar :)

Amikor valaki úgy írja, hogy "Mi a baj a multithread-el?", akkor az azért bántja a fülemet, mert én úgy olvasom, mint mondjuk azt, hogy "Mi a baj az ebédel?". "ebéddel" helyett. Persze biztos van aki nem így "hangosan" olvas belül a fejében :)
--
♙♘♗♖♕♔

Most ízlelgetve valóban, de szerintem csak azért, mert beleraktad a bogarat a fülembe. :) Mert egyébként meg nem, in pattern matchelek, és azt olvasom "hangosan" a fejemben. Regényeknél típikus, hogy félúton tűnik fel, hogy egyik másik szereplőt nem is egészen úgy hívják, ahogy én olvasom :)

szóval ízlés kérdése, na. És ezért jobb ilyenekről beszélni, mint azzal érvelni, hogy "azaszabáj", mert így még tán szélesedik is az ember világlátása :)

Idézet:
az összes, magyar fonetikába rosszul illeszkedő külföldi szó katasztrofálisan szarul olvasható a helyes írásmóddal

A magyar fonetikába rosszul illeszkedő külföldi szavak helyes írásmódja a kötőjeles toldalékolás.

Viszont a multithread nem illeszkedik rosszul a magyar fonetikába, ezért nem kell kötőjellel írni.

a szabályt ismerem, csak a rosszul illeszkedés definíciója változik egyénenként :)

+1

Lehet, bonyolítaná a dolgokat, annyit meg nem nyernél sebességben, de csak tipp, a nyelvtannácikkal meg nem kell törődni.

Meg az idiótákkal sem.

--

nTOMasz
"The hardest thing in this world is to live in it!"

Meg ugy altalaban senkivel:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Necromancer vagyok. :-p

Mi a baj a multi threaddel? Alábbiakban vázolom.

* egy chat alkalmazás akkor jó, ha az üzenetek azonnal, várakozás nélkül átmennek a feladótól a címzetthez
* a kliens a szerver oldalról webes alkalmazás esetén websocket-et használ, esetleg long polling-ot ha muszáj. Desktop/mobil app esetén meg normál socket-et. Mindkét esetre igaz, hogy a kliens kiküldi a kérést, és a kapcsolat megszakítása nélkül várja a választ.
* tehát ha sok a user, akkor a szerveren egyszerre több request is várakozik response-ra. *sok aktív request van egyszerre*

Egy multi threaded szervernél ez azt jelenti, hogy *sok* szál van egyszerre. A sok alatt itt nem azt kell érteni hogy 100, hanem hogy mondjuk 100 ezer. A szálak közötti váltogatás meg olyan context switching-et csinál, hogy a géped akkor is le van terhelve, ha nem csinál semmit. Nem hatékony!

Ezzel szemben az async io-s megoldás minden aktív request-re egy file descriptor-t nyit, és ha senki nem küld üzenetet, akkor a szerver se csinál semmit. Ha bejön az üzenet (alacsony szinten: megszakításból), akkor a kernel beteszi a pufferbe az adatcsomagot, és szól a szervernek hogy itt egy adat, dolgozd föl. Az meg feldolgozza, és kiküld egy másik csomagot annak a kliensnek, aki épp azt várja. Nincsen sok szál csak egy, és ha nincs üzenetváltás, akkor a szerver pihen. Mivel csak egy szál van, ezért nincs shared memory, nincs szükség lock-olásra, nincs context switching stb. És a kódban nincs olyan hogy "jaj még nem jött üzenet várjunk egy kicsit hátha jön", mert minden eseményvezérelt.

Az async io-val írt kód eseményvezérelt. Ez olyan problémák megoldására jó, amiknél eseményeket kell kezelni. A chat tipikusan ilyen. A nagyon sok useres chat meg főleg ilyen.

Konkrétan egy async io-val megvalósított szerver egy gyengécske, több éves vason is simán kiszolgál 100 ezer nyitott kapcsolatot egyszerre. (Feltéve hogy nem beszélget egyszerre az egyik fele a másikkal.) Ha jól van megírva, akkor eközben alig használ memóriát meg CPU-t.

Próbáld meg ugyanezt megvalósítani multi thread-es szerverrel. 100 ezer nyitott kapcsolat az vagy 100 ezer szál, vagy elkezdhetsz ügyeskedni greenlet-ekkel meg microthreads-el, de sosem lesz igazán jó.

"Próbáld meg ugyanezt megvalósítani multi thread-es szerverrel. 100 ezer nyitott kapcsolat az vagy 100 ezer szál, vagy elkezdhetsz ügyeskedni greenlet-ekkel meg microthreads-el, de sosem lesz igazán jó."

És az async io meg a multi thread együtt megvalósítva hova álljon? :D

Nyugi, elrejti az engine. Modern körökben a nodejs alatt már úgy sincs semmi más, ha meg van is azt majd elrejti a docker ;)


// Happy debugging, suckers
#define true (rand() > 10)

Az asyncio és a multithread természetesen jól megférnek egymás mellett. Amit mondtam azt természetesen nem úgy kell értelmezni, hogy egy ilyen chat szerverben ki kell zárni a több thread-et. Ezt úgy kell érteni, hogy a chat kliensek kiszolgálását (a bejövő request-eket és az arra való válaszadást mint eseményt) érdemes async io-val kezelni. Ez nem zárja ki azt, hogy más dolgok külön szálakban fussanak. De azt igen, hogy minden bejövő kérésnek külön szál legyen.

Az a kollega meg aki a thread pool-ról kérdezett, talán nem gondolta át hogy mit is jelent az, hogy egyszerre sok ezer aktív request (vagy "nyitott websocket") van. Ezeket értelmes módon nem lehet máshogy kezelni, csak egy I/O loop segítségével.

"Próbáld meg ugyanezt megvalósítani multi thread-es szerverrel. 100 ezer nyitott kapcsolat az vagy 100 ezer szál"
Miért lenne?
Threadpoolról hallottál már?

"Konkrétan egy async io-val megvalósított szerver egy gyengécske, több éves vason is simán kiszolgál 100 ezer nyitott kapcsolatot egyszerre."
És nem fog tudni egy CPU fölé skálázódni.

> Threadpoolról hallottál már?

Így igaz, lehet használni Threadpoolt, ami áthidalja a fenti problémát, de nem oldja meg.

> És nem fog tudni egy CPU fölé skálázódni.

Így igaz, sőt 1 mag fölé sem tud skálázódni.

> Nyugi, elrejti az engine. (by Mcsiv)

Ha az "engine elrejti", akkor nagy valószínűséggel az vagy az egyiket (multithread) vagy a másikat (async io egy threaden) fogja jelenteni, vagy ha a kettő kombinációját is, akkor sem feltétlen azt, ami a működés logikája szempontjából kívánatos lenne.

A fentiek miatt az igazán jó megoldás az, ha az alkalmazás készítője tudja kvázi megmutatni az "engine"-nek, hogy mi legyen több szálú és mi legyen async egy szálon.

Lásd pl. az Actor modellt, itt egy példa, ami a fenti problémát is valamelyest tartalmazza.

Ez, ez és ez további példák NodeJS, Java, JEE és Actor modellre.

> Threadpoolról hallottál már?

A thread pool nem megoldás ott, ahol egyszerre sok ezer aktív request van (amire a response csak hosszú idő után fog kimenni). A chat pedig pont ilyen.

A threadpool nem feltétlenül azt jelenti, hogy a threadben alszol.

> És nem fog tudni egy CPU fölé skálázódni.

Ez igaz! Azonban a chat szerver az nem CPU bound hanem I/O bound probléma. Nem is kell fölé skálázódnia. De ha mégis, akkor arra még mindig van olyan megoldás, ami több processzre (akár több gépre) bontja szét a csatlakozó klienseket, akik egymás között egy szerveren keresztül kommunikálnak.

Ez a fajta megközelítés már horizontálisan tetszőlegesen skálázható, és az egyedüli igazi korlát az az egy chat szobában levő személyek száma. (És ha megnézitek a skype és más nagy szolgáltatók programjait, akkor ott is pontosan ez az a dolog ami korlátos. Nem véletlenül!)

Jájj! Az, hogy multithread biztosan azt jelenti, hogy minden egyes user-nek kell külön thread?

Nem biztosan azt jelenti. Természetesen egy rendes chat szerverben lesznek szálak. A hangsúly itt azon van, hogy a bejövő és kimenő chat üzeneteket egy I/O loop-ban async módon dolgozod föl, vagy mindegyiket külön szálban. Erre mondtam én azt, hogy a több szálas megoldás biztosan nem jó, konkrétan erre a problémára. Az async io-s pedig jó, konkrétan erre a problémára.

Persze lehet azt mondani, hogy ha van benne több szál akkor az már többszálú. De ez csak kötekedés. Nem volt szándékom kizárólagosságot sugallni. Csak a kérések kiszolgálásának alapelvére akartam átadni tudást, ami egyaránt alapul saját tapasztalaton, és kollektív tudáson.

Ha valakinek más véleménye van, és úgy dönt hogy más irányba indul el, akkor hajrá! Még az is lehet hogy jól meg tudja csinálni máshogy is. Én nem ítélkezem. Majd ítélkezik a tapasztalat!

Az egy szálon lévő I/O loop-nál azért létezik hatékonyabb megoldás, pl. completion portok egy olyan thread pool-ban, amiben pont annyi szál van, ahány CPU mag. Így továbbra is aszinkron marad minden, a szálak száma nem a kérésekével, hanem a magokéval arányos, és akár egyszerre több kérésen is dolgozhat a szerver, ha már ott van benne a sok mag.

Mondok jobbat: tudsz kezelni logikai szálakat is, nem kell feltétlen se operációs rendszer szintjén szálakat kezelni, se CPU szintjén. :)

Na ez még jobban hangzik. Bár egy chat szerver akkor is I/O bound lesz, és ebben a konkrét esetben úgysem tudod kihasználni a több CPU-t. De az alapelv jó.

A littles law-t nem ismertem, de átolvastam és igen. Erről van szó. :-)

Aki multi threading-es chat szervert akar írni az meg fogja tapasztalni a benne rejlő igazságot.

Csak bennem merul fel, hogy nem nekiallnek programot irni, hanem esetleg keresnek egy kesz megoldast (esetleg kis testreszabassal)?

Kezdetnek lehetne pl: apt install talkd :)

mindegy mi csak javascript legyen. Minden egyéb nyelv ki fog halni, mint az assembly.
Tavaly hajigáltam ki a régi asm könyveimet.
Kell 200 ember aki a webkitet fejleszti a többi meg tolja a js-t.
Steve Jobsnak igaza volt ebben is, csak megelőzte a korát egy kicsit.
Ha nem elég a vas akkor a kínaiak legyártanak 1 dollárért még egy szervert.
Jobban megéri mint évi 500 ezer dollárt fizetni egy c++ programozónak.

--
GPLv3-as hozzászólás.

:-)

Ehhez kapcsolódóan minap felvetődött bennem a kérdés, hogy mi motivál egy projektet, hogy egy kevésbé ismert programozási nyelvet válasszon, egyúttal a nyelv fejlődését is felkarolja?

Itt van például a pár éve még alig ismert Rust.
A Mozilla alapítvány döntött néhány éve, hogy abban írja újra a Firefoxot.

Milyen előnye van neki? Miért döntöttek az addig kevésbé ismert Rust mellett szemben a népszerű programozási nyelvekkel?

A fejlesztő is ember. Ha ugyanazt ugyanúgy csinálná, mint a többi fejlesztő, akkor unalmas lenne a munkája. Ezért kitalálja, hogy ő mit fog másképp csinálni, aztán meggyőzi a managementet, hogy jó ötlet.

Talan mert modern nyelv es olyan kepessegei vannak, amik az elavult nyelveknek nincs. Ennek koszonhetoen csomo szivastol kimelik meg magukat. pont ma talaltam ezt a cikket. Es ok a Pony-t valasztottak, es azert mert:
type safe
memory safe
data-race free
dead-lock free
compatuble with C

Kevesebb melo volt a hianyzo libeket lefejleszteni, mint mas nyelvben megoldani ezeket a problemakat.

-
Kiterjesztések írása Go nyelvi környezetben

Vibe.d jó választás erre a célra, van benne szál, modern fiber, stb.

"Mi az amit, biztosan nem hasznalnal?" - kedvenc játékszer mentalitással rendelkező fejlesztő tanácsát

Olyan, hogy reális esély nincs, csupán hit, amelyeket statisztikákkal, profibb growth marketinggel próbálsz megerősíteni, prevalidációkkal, majd ez később kiderül, hogy bejött-e. Épp ezért kell egy kiindulási alapnak MVP-t letenni, amilyen gyorsan csak tudtok, ahelyett hogy hetekig azon morfondíroztok, hogy milyen hipszter nyelvben, libbel indulsz az álmod megvalósításához. Kurva sokat fog változni, felesleges.

Pl ha a csapatod egyik tagja azt mondja, hogy na de ezt c-ben kell megírni, a többiek meg nem konyítanak hozzá egyáltalán, és még is ebben fejlesztesz, akkor nagy eséllyel tökön lövöd magad. Érdemes olyat választani, amelyhez az adott megvalósítandó core featurehez van támogatás, tapasztalat - akár külső. Nem véletlenül nem mezei fejlesztő dönt ilyen kérdésekben.

Bármely mainstream nyelv alkalmas rá, bárki bármit mond, de nyilván ne brainfuckban. Igen, node is - bár szvsz egy Typescript-el érdemes megtámogatni -.

(MVP - minimum viable product)

> Nem véletlenül nem mezei fejlesztő dönt ilyen kérdésekben.

Hanem a Pointy-haired Boss, akit a Dilbert-képregényekből ismerünk...
https://en.m.wikipedia.org/wiki/Pointy-haired_Boss

Maradjunk annyiban, hogy o se, mert ez nem csupan uzleti, hanem technologiai dontes is.

De nyilvan lehet ezt onerzosen sertesnek is felvenni, de akkor -1 lepes es mar menedzsment problemank van.

ha mar feleledt egy kisse a topik, akkor az en 2 centem:

Van ra realis esely, hogy tobbmillio aktiv usered lesz

igen, kb. 10^-5. Ezert olyan technologiakat valasztanek hozza, amit jol ismerek, minel hamarabb elindulnek az mvp-vel. Aztan ha osszejon 1k konkurens juzer, akkor orulok, 10k-nal meg leulunk, es atgondoljuk, hogyan tovabb. De addig a skalazodason tokolni overkill es haszontalan idorablas...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

+1 skalazni csak abban az - aldott - szakaszban ajanlott, amikor ez tenyleg problema. Egy adott termek fejlesztesi strategiajaban vannak fontosabb szempontok, mint olyanra keszulni, ami egy kvazi alom meg csak ebben a stadiumban.

> Ma el kene kezdened egy chatprogram protokolljanak/szerverenek implementalasat.

Ha szabad tudni, akkor végül miben kezdtétek el?

elmeletben:))

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Az 'elméletben' azért feltételez valamennyi megvalósíthatóságot... megvalósíthatóság nélkül álmodozásnak hívják. És van, aki csak eddig jut... :)