Proč je čtení ze Socketu blokjící operace?

mhi_

Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #15 kdy: 31. 07. 2018, 14:07:19 »
http://www.boa.org/ tady mate nonblocking single-thread server, ktery slouzi jako dobry priklad jak to napsat bez knihoven.

Mam za to, ze dobre napsany automat bude vzdy rychlejsi, nez multithreadovy server. Zasadni problem, na ktery se dnes narazi jsou SMP a load-balancing jednotlivych threadu resicich to same aby vytizily vsechna CPU.


gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #16 kdy: 31. 07. 2018, 14:23:59 »
Ještě by to chtělo nějaký benchmark, kde výstupem bude graf závislosti doby zpracování requestu na počtu vytvořených threadů.

Představoval bych si to tak, že udělám Server, který bude na obyč socketu naslouchat. Thread poolu nastavím fixně 2000 threadů. Každému requestu dá z poolu 1 thread. Ten thread na 6000ms uspí a potom odepíše OK, takže ten thread nebude vlastně celou dobu nic dělat. Potom porovnám dobu zpracování toho requstu minus 6000ms a bude mě zajímat, jak roste doba obsloužení 1 requestu s rostoucím počtem spících threadů.

Ve smyčce bych dal každých 3ms vytvořit z threadpoolu thread pro 1 request přes socket, takže za těch 6000ms by to mělo udělat celkem necelých 2000 threadů.

Akorát problém tady je, že ten Thread.sleep() úplně nepředstavuje správnou blokující operaci. Nebo jo? To si obsluhuje Java předpokládám, kdy má který thread probudit.

nejde o rychlost, ale o škálovatelnost. Zátěž při přidávání vláken neroste lineárně. Do určitého počtu vláken bude ten thread pool stejně rychlý, možná i rychlejší. Ale co když tu aplikaci bude používat víc než 2000 uživatelů současně? Zatím tu nezazněl jediný argument proti neblokujícímu IO. Děláš raketovou vědu z něčeho, co lze napsat na 3 řádky tak, že to obslouží 2 miliony spojení.
« Poslední změna: 31. 07. 2018, 14:26:39 od gll »

Ivan

Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #17 kdy: 31. 07. 2018, 14:45:55 »
Zrovna jsem přemýšlel nad tím, proč Java spotřebuje nutně na každou blokující operaci jeden thread.

Je porad jeste pravda? Drivejsi JVM API nemelo neco jako epoll, ale tohle uz IMHO neplati.

xxx


Jirsák

Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #19 kdy: 31. 07. 2018, 15:06:29 »
Jirsák je zde!


borekz

  • ****
  • 474
    • Zobrazit profil
    • E-mail
Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #20 kdy: 31. 07. 2018, 15:55:13 »
s proměnnou s pracujete stejně jako se souborem, jen před blokující operace přidáte await a před for smyčku dáte async. Žádná věda.
To je ale v podstatě vlákno, jen je to řešené na úrovni jazyka místo operačního systému a ne všechny jazyky to umí.

anonym

Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #21 kdy: 31. 07. 2018, 17:49:13 »
Coz me privadi k otazce jak funguje projekt Quasar, protoze ten sice umi delat fibery, ale kdyz vlakno spadne do blokujici operace v nativním kódu, třeba u jdbc, tak proste Quasar nemuze podle me delat proste nic. Nebo muze? Proste 1 blokujici operace v nativním kódu = 1 thread. Muze udelat maximalne to, ze tu situaci detekuje a vytvori nove vlakno, aby mohl dal multitaskovat mezi fibery.

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #22 kdy: 31. 07. 2018, 18:30:00 »
s proměnnou s pracujete stejně jako se souborem, jen před blokující operace přidáte await a před for smyčku dáte async. Žádná věda.
To je ale v podstatě vlákno, jen je to řešené na úrovni jazyka místo operačního systému a ne všechny jazyky to umí.

je to abstrakce nad neblokujícím IO. Nějakou formu kooperativního multitaskingu umí všechny jazyky. Z principu je to jednodušší než vlákna.

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #23 kdy: 31. 07. 2018, 18:41:39 »
Coz me privadi k otazce jak funguje projekt Quasar, protoze ten sice umi delat fibery, ale kdyz vlakno spadne do blokujici operace v nativním kódu, třeba u jdbc, tak proste Quasar nemuze podle me delat proste nic. Nebo muze? Proste 1 blokujici operace v nativním kódu = 1 thread. Muze udelat maximalne to, ze tu situaci detekuje a vytvori nove vlakno, aby mohl dal multitaskovat mezi fibery.

pokud potřebuješ používat nějakou blokující knihovnu, tak se to řeší tak, že blokující operace spustíš v thread poolu.

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #24 kdy: 31. 07. 2018, 18:59:39 »
Coz me privadi k otazce jak funguje projekt Quasar, protoze ten sice umi delat fibery, ale kdyz vlakno spadne do blokujici operace v nativním kódu, třeba u jdbc, tak proste Quasar nemuze podle me delat proste nic. Nebo muze? Proste 1 blokujici operace v nativním kódu = 1 thread. Muze udelat maximalne to, ze tu situaci detekuje a vytvori nove vlakno, aby mohl dal multitaskovat mezi fibery.

pokud potřebuješ používat nějakou blokující knihovnu, tak se to řeší tak, že blokující operace spustíš v thread poolu.

konkrétně ten Quasar framework má metodu runBlocking, které předáš jako první parametr thread pool.

https://docs.paralleluniverse.co/quasar/javadoc/co/paralleluniverse/fibers/FiberAsync.html#runBlocking(java.util.concurrent.ExecutorService,%20co.paralleluniverse.common.util.CheckedCallable)

anonym

Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #25 kdy: 31. 07. 2018, 19:06:46 »
Coz me privadi k otazce jak funguje projekt Quasar, protoze ten sice umi delat fibery, ale kdyz vlakno spadne do blokujici operace v nativním kódu, třeba u jdbc, tak proste Quasar nemuze podle me delat proste nic. Nebo muze? Proste 1 blokujici operace v nativním kódu = 1 thread. Muze udelat maximalne to, ze tu situaci detekuje a vytvori nove vlakno, aby mohl dal multitaskovat mezi fibery.

pokud potřebuješ používat nějakou blokující knihovnu, tak se to řeší tak, že blokující operace spustíš v thread poolu.

konkrétně ten Quasar framework má metodu runBlocking, které předáš jako první parametr thread pool.

https://docs.paralleluniverse.co/quasar/javadoc/co/paralleluniverse/fibers/FiberAsync.html#runBlocking(java.util.concurrent.ExecutorService,%20co.paralleluniverse.common.util.CheckedCallable)

Haha, no to jsem si myslel. Takže v tom případě je Quasar k čemu? Quasar nechceš na paralelní výpočty, ale když už, tak na blokující operace. Jenže k čemu ti to je, když to stejně potřebuje thread pool. To jsi zase na začátku, 1 thread 1 blokující operace. A v momentě, když bych měl asynchronní JDBC, tak na co mi je quasar? Vždyť to si raději udělám 1 thread co bude volat ve smyčcce Available() nad všema JDBC dotazama, na to zase nepotřebuju Quasar. Resp. nebudu si to dělat já, ale určitě vzniknou ConnectionPooly které to takto budou umět.

anonym

Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #26 kdy: 31. 07. 2018, 19:10:32 »
Prostě dokud nebude asynchronní JDBC, tak tohle všechno ohledně Threadů můžu pustit tak akorát z hlavy, protože 1 JDBC query 1 thread no matter what, s quasarem či bez něj. Takže si můžu dál z vesela používat Tomcat a staré Servlety, co dělají 1 thread per request.

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #27 kdy: 31. 07. 2018, 19:15:39 »
Coz me privadi k otazce jak funguje projekt Quasar, protoze ten sice umi delat fibery, ale kdyz vlakno spadne do blokujici operace v nativním kódu, třeba u jdbc, tak proste Quasar nemuze podle me delat proste nic. Nebo muze? Proste 1 blokujici operace v nativním kódu = 1 thread. Muze udelat maximalne to, ze tu situaci detekuje a vytvori nove vlakno, aby mohl dal multitaskovat mezi fibery.

pokud potřebuješ používat nějakou blokující knihovnu, tak se to řeší tak, že blokující operace spustíš v thread poolu.

konkrétně ten Quasar framework má metodu runBlocking, které předáš jako první parametr thread pool.

https://docs.paralleluniverse.co/quasar/javadoc/co/paralleluniverse/fibers/FiberAsync.html#runBlocking(java.util.concurrent.ExecutorService,%20co.paralleluniverse.common.util.CheckedCallable)

Haha, no to jsem si myslel. Takže v tom případě je Quasar k čemu? Quasar nechceš na paralelní výpočty, ale když už, tak na blokující operace. Jenže k čemu ti to je, když to stejně potřebuje thread pool. To jsi zase na začátku, 1 thread 1 blokující operace. A v momentě, když bych měl asynchronní JDBC, tak na co mi je quasar? Vždyť to si raději udělám 1 thread co bude volat ve smyčcce Available() nad všema JDBC dotazama, na to zase nepotřebuju Quasar. Resp. nebudu si to dělat já, ale určitě vzniknou ConnectionPooly které to takto budou umět.

je rozdíl mezi socketovým spojením, které trvá hodiny. A databázovým dotazem/souborovou operací/http requestem, které trvají zlomek sekundy. Jestli ti vadí blokující legacy knihovny, tak přejdi na javascript, kde je vše navenek neblokující (i když vnitřně pro některé operace vlákna používá).

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #28 kdy: 31. 07. 2018, 19:19:54 »
Prostě dokud nebude asynchronní JDBC, tak tohle všechno ohledně Threadů můžu pustit tak akorát z hlavy, protože 1 JDBC query 1 thread no matter what, s quasarem či bez něj. Takže si můžu dál z vesela používat Tomcat a staré Servlety, co dělají 1 thread per request.

databázový server stejně spouští dotazy ve vláknech. S 1 thread per request narazíš jakmile začneš používat websockety, long pooling a podobně.
« Poslední změna: 31. 07. 2018, 19:23:08 od gll »

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Proč je čtení ze Socketu blokjící operace?
« Odpověď #29 kdy: 31. 07. 2018, 20:14:43 »
Vždyť to si raději udělám 1 thread co bude volat ve smyčcce Available() nad všema JDBC dotazama, na to zase nepotřebuju Quasar.

Ta smyčka by ti zablokovala zbytek aplikace. Jestli se chceš naučit moderní aynchronní programování, doporučuji Javascript. Quasar má neskutečně ošklivé API.