Non-blocking IO

Hi guys,

I'm wondering whether Pharo support any form of non-blocking IO. You can
find such IO support in Node.js or Java NIO packages and on Linux they use
select/poll async IO system calls.

An example scenario is to be able to schedule 10 concurrent HTTP calls
taking 1-5s and wait for them to finish. Naturally, if you perform the calls
sequentially you'll wait for much longer than if you fire the calls
concurrently.

Is it possible in Pharo? I've only spent a few hours reading about the
platform but I'm still not sure whether the built-in process/threading
supports such scenario.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

I think you can do what you describe if you use #fork to create separate
processes for each of your concurrent HTTP calls.

Here's an example -- Try the following (from
http://forum.world.st/Teaching-fork-td4786444.html)

10 timesRepeat: [ (Delay forSeconds: 1) wait. Transcript show: 'hello'; cr
].

Then the following :
[ 10 timesRepeat: [ (Delay forSeconds: 1) wait. Transcript show: 'hello'; cr
]] fork.

You can also spawn OS sub-processes:
https://github.com/pharo-contributions/OSSubprocess

-t



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Asynchronous I/O and non-blocking I/O are very different things.
The POSIX aio* functions are asynchronous, not non-blocking.
The "conventional" Unix way to do asynchronous I/O is to start a new
thread for the transfer.  The new thread uses ordinary synchronous
I/O and then responds to completion any way you want.  It is a rather
easier model to program for than asynchronous I/O.

On Mon, 20 Apr 2020 at 04:15, dturczanski <[hidden email]> wrote:

Thanks for pointing out the difference between non-blocking and async IO. I
think in Java NIO there is a thread that constantly calls the [e]poll() in
the background and this way the IO becomes non-blocking.




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Thanks. Are there any benchmarks available for Pharo HTTP servers? Is it
possible to achieve a performance similar to node.js? I know the biggest
selling point of Smalltalk is not perf but still I'm curious.

The Concurrency book [1] says that Pharo's Process is like a fibre and is
lightweight. How big is the stack? Java Quasar's fibers are very lightweight
with a 400 byte stacks [2]. Can you have hundreds or thousands of processes
running blocking IO without much memory and performance penalty?

[1] http://books.pharo.org/booklet-ConcurrentProgramming/
[2]
https://docs.paralleluniverse.co/quasar/javadoc/co/paralleluniverse/fibers/Fiber.html



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Daniel,

> On 24 Apr 2020, at 12:35, Daniel Turczański <[hidden email]> wrote:
>
> Thanks. Are there any benchmarks available for Pharo HTTP servers? Is it
> possible to achieve a performance similar to node.js? I know the biggest
> selling point of Smalltalk is not perf but still I'm curious.

Benchmarking is a black art with many pitfalls.

Let's say that Pharo HTTP performance is acceptable.

Here is a test that I just ran (on a LXC/LXD container on a big production server).

t3@t3-pharo-test:~/tmp/pharo9$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"

t3@t3-pharo-test:~/tmp/pharo9$ curl get.pharo.org/64/90+vm | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3054  100  3054    0     0   198k      0 --:--:-- --:--:-- --:--:--  198k
Downloading the latest 90 Image:
    http://files.pharo.org/get-files/90/pharo64.zip
Pharo.image
Downloading the latest pharoVM:
        http://files.pharo.org/get-files/90/pharo64-linux-stable.zip
pharo-vm/pharo
Creating starter scripts pharo and pharo-ui

t3@t3-pharo-test:~/tmp/pharo9$ ./pharo Pharo.image printVersion
[version] 'Pharo9.0.0' 'Pharo-9.0.0+build.252.sha.fe2815c89f309789cbfba9a1ce821fb959dfe987 (64 Bit)'

t3@t3-pharo-test:~/tmp/pharo9$ ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' &
[1] 32203
a ZnManagingMultiThreadedServer(running 1701)

t3@t3-pharo-test:~/tmp/pharo9$ curl http://localhost:1701/random
0BFE44ECF0BEEDDD949A8D5A363E5E6192A4B7CD4939E8BD7A7C7EC69995157

t3@t3-pharo-test:~/tmp/pharo9$ ab -k -n 1024 -c 8 http://localhost:1701/random
This is ApacheBench, Version 2.3 <$Revision: 1807734 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 102 requests
Completed 204 requests
Completed 306 requests
Completed 408 requests
Completed 510 requests
Completed 612 requests
Completed 714 requests
Completed 816 requests
Completed 918 requests
Completed 1020 requests
Finished 1024 requests


Server Software:        Zinc
Server Hostname:        localhost
Server Port:            1701

Document Path:          /random
Document Length:        64 bytes

Concurrency Level:      8
Time taken for tests:   0.246 seconds
Complete requests:      1024
Failed requests:        0
Keep-Alive requests:    1024
Total transferred:      256000 bytes
HTML transferred:       65536 bytes
Requests per second:    4155.22 [#/sec] (mean)
Time per request:       1.925 [ms] (mean)
Time per request:       0.241 [ms] (mean, across all concurrent requests)
Transfer rate:          1014.46 [Kbytes/sec] received


This is a small, do nothing request, tested locally, and so on.

I would say it is safe to say you can handle 100s to 1000s of requests per second on a single Pharo instance (which is using only a single core).

The good thing about HTTP is that you can normally scale horizontally by adding more and more worker instances under a load balancer -- these are standard techniques.

HTH,

Sven

Thanks Sven! Looks good to me.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html