Příspěvky

181

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 01. 08. 2018, 15:24:56 »

Kdo říká že nemůžu dělat async s Feature nad vlákny. Vypadalo by to kompletně stejně, ať už pod tím byly vlákna nebo fibery.

A těch 100x více spojení bych měl k čemu? Tisícovky spojení vám nestačí?  Na takovou webovou službu, kde máte tolik spojení, už si snad vyhradíte samostatný server, protože to poslední co řešíte je pár tisícovek za PC. A pokud bych na to něco opravdu potřeboval 100x více spojení, tak to by byla nějaká supervýkonná lehká služba a na to zase se můžu vyprdnout rovnou na Javascript, to už snad udělám tuhle věc raději nějak v C/C++ ne?

Tady podle mě to v te Javě není zase tak špatné, když nebudu odříznutý od reality tak je to dostačující pro 95% usecase na trhu práce.

klidně to naprogramuj v assembleru. Stále to bude řádově nenažranější než javascriptový event loop.

182

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 01. 08. 2018, 14:11:37 »

bez vláken by to bylo o 80% procent kratší a zvládlo by to 100x víc spojení.

S vlákny taky, jen je potřeba to napsat správně. Dělat a spravovat si v Javě vlákna ručně je nesmysl už hodně let..

Použijte třeba cached thread pool a úlohy do něj posílejte. Nové vlákno se tím vytvoří dle potřeby a stará vlákna se znovupoužijí nebo ukončí podle zátěže.

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool--
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html#submit-java.lang.Runnable-

thread pool je pro dlouhotrvající spojení nesmysl. Potřebujete jedno vlákno na spojení.

183

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 01. 08. 2018, 13:29:13 »

Kód: [Vybrat]

@RunWith(JUnit4.class)
public class Play {

    private static final long RESPONSE_DELAY = 100000;
    AtomicLong count = new AtomicLong(0);
    AtomicLong sumTime = new AtomicLong(0);


    class SocketRespond implements Runnable {
        private final Socket socket;

        public SocketRespond(Socket socket) {
            this.socket = socket;
        }

        @Override
        public void run() {
            try (OutputStream os = socket.getOutputStream()) {
                OutputStreamWriter w = new OutputStreamWriter(os);
                PrintWriter p = new PrintWriter(w);
                Thread.sleep(RESPONSE_DELAY);
                p.println("OK");
                p.flush();
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                try {
                    socket.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
    }

    class ServerListener implements Runnable {
        ServerSocket serverSocket;

        @Override
        public void run() {
            try {
                serverSocket = new ServerSocket(6666);
                out.println("Srv start");
                while (true) {
                    Socket newConnection = serverSocket.accept();
                    Thread t = new Thread(new SocketRespond(newConnection));
                    t.start();
                }
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    @Test
    public void start() throws IOException, InterruptedException, ExecutionException {
        Thread serverThread = new Thread(new ServerListener());
        serverThread.start();

        Thread.sleep(300);

        
        for(int i = 100; i< 10000; i*=2) {
            List<Thread> threads = new ArrayList<>();
            for(int j = 0; j < i; j++) {
                Thread sockTh = new Thread(new Runnable() {
                    @Override
                    public void run() {
                        try {
                            connect();
                        } catch (IOException e) {
                            e.printStackTrace();
                        }
                    }
                });
                Thread.sleep(5);
                threads.add(sockTh);
                sockTh.start();
            }

            for(Thread t2 : threads) {
                t2.join();
            }

            out.println("Threads " + i + " time " + sumTime.get() / count.get());
            sumTime.set(0);
            count.set(0);
            threads.clear();
        }


    }
    
    public void connect() throws IOException {
        long timer = System.currentTimeMillis();
        Socket s = new Socket("127.0.0.1", 6666);
        BufferedReader b = new BufferedReader(new InputStreamReader(s.getInputStream()));
        String str = b.readLine();
        timer = System.currentTimeMillis() - timer;

        Assert.assertEquals(str, "OK");

        count.incrementAndGet();
        sumTime.addAndGet(timer - RESPONSE_DELAY);
        b.close();
        s.close();
    }
}

bez vláken by to bylo o 80% procent kratší a zvládlo by to 100x víc spojení.

184

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 01. 08. 2018, 13:25:43 »

javascript

V browseru si klidně používejte Promises nebo PubSub. Já si to na jednojádrovém mikrokontroleru s 8 kiB RAM dovolit nemůžu. Stejně je to jen syntaktický cukr, který obaluje interně připravenou callback funkci.

javascript má coroutiny. Mikrokontrolery bych do diskuze vlákna vs. non-blocking IO nezatahoval.

185

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 31. 07. 2018, 22:14:16 »

Podobna ochcavka je predani callbacku.

což nikdo normální dávno nepoužívá.

186

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 31. 07. 2018, 22:11:13 »

A tady je výsledek měření. Měl jsem Socket server, které každému připojení udělal Thread a nechal ho čekat 100 vteřin. Potom odeslal "OK" a socket i thread ukončil.

Client vytvářel sockety , připojující se na server každých 5ms. Výsledek dole Threads znamená, kolik vlastně chrápalo na serveru paralelně thradů s připojenými sockety.

Jen ještě upozorňuju, že počet vytvořených Threadů je dvojnásobný: jedenkrát za client sockety a jedenkrát za server accepty.

Threads 100 time 1
Threads 200 time 1
Threads 400 time 1
Threads 800 time 1
Threads 1600 time 0
Threads 3200 time 0
Threads 6400 time 0

Výsledek je, že zde není naprosto žádný overhaul kvůli vysokému množství threadů. Ty thready prostě chrápou a basta, a potom začnou každých 5ms odpovídat "OK".

postni sem kód.

187

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 31. 07. 2018, 22:09:42 »

No, asi z trochu jiného pohledu, Windows mi žerou zvesela 1500 threadů průběžně. Podle stackoverflow

https://stackoverflow.com/questions/373098/whats-the-average-requests-per-second-for-a-production-web-application

Wikipedie měla 100-200 requestů za vteřinu na 1 server. To se dá v pohodě utáhnout stylem 1 request/1 thread, na to nepotřebuju vymýšlet Quasary a Javascripty. I bych mohl klidně z poolu mít udělaných na každý request 10 threadů, takže až 2000 threadů, to PC s Linuxem musí úplně v pohodě zvládnout.

Já jsem zkoušel udělat si 15000 spících threadů a systém to nijak nevytěžuje. Dokonce ani není pravda očividně to, že 1 thread = 1 mb v RAM, to ani náhodou neodpovídalo realitě, spíše mi to přijde jako nanejvýš třetinová hodnota.

Takže asi to v praxi nebude s tím bezthreadovým async zase tak horké. Takže let's go na JDBC a Servlety, tohle je jen takový hype bez kterého se svět nezblázní.

bavíme se o socketových spojeních nebo o requestech? 100-200 requestů za vteřinu může být klidně 100 tisíc uživatelů s otevřenou wikipedií. Pokud využíváš websockety jen pro nějakou okrajovou funkcionalitu, jako např. notifikace, tak nevím, proč by to mělo žrát polovinu výkonu a paměti serveru.

188

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

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

189

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

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

190

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« 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á).

191

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

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

192

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

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

193

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

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

194

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

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

195

Studium a uplatnění / Re:Freelancing z Thajska

« kdy: 30. 07. 2018, 23:50:58 »

dire plny fetu, levnejch stetek a trandaku

okolí Václaváku v Praze?