From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Performance of many concurrent delay() calls Date: Mon, 7 Nov 2016 21:57:18 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <1a375eea-b087-4080-a492-62bc26a8123c@googlegroups.com> NNTP-Posting-Host: s3c6wwRqkurrfTZpuYYZ+w.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:32264 Date: 2016-11-07T21:57:18+01:00 List-Id: 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