Re: Performance of many concurrent delay() calls

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2016-11-07 19:52, Olivier Henley wrote:

> Does calling [loop and delay(1.0)] for each of many thousand
> connected  clients (gnoga/simple components) is a huge performance hit or not?

I am not sure what you mean. Simple Component's server is specifically 
designed to handle multiple/all connections from one task. A delay on 
the context of that task is not a performance hit it is a catastrophe.

> If so, what is the recommended way to implement a periodic, every
> sec,  procedure that has to run for every clients; instantiate a single main
> task looping, delay(1.0), over all connections data and call the wanted
> procedure... probably?

That depends on what the periodic procedure is supposed to do. You 
cannot read any data from an external task, but you can queue data to 
send if the client's output buffer is not full. You can also allocate 
secondary buffers, there is a primitive operation called when a portion 
of data is sent. It is called on the server's task context and can be 
used to push data from the secondary buffer(s) into the freed portion of 
the primary buffer.

As for creating an external task for each client, that would defeat the 
purpose of the design (an OS can have a large number of sockets and only 
a limited number of tasks). So if any external tasks created they should 
loop over multiple clients.

How many external tasks and how many server tasks is a question of 
balance between CPU / Ethernet controller / network load. As J-P said, 
there is no way to foresee it. You have to measure.

Finally, there is a simple method of having non real-time *short* 
periodic activity per client. You override receive or send callback and 
check if the period is expired since latest periodic call. If yes you 
note the time (in the client) do that call again. If there is steady 
socket I/O that would work.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de