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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b056670d07cef927,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-16 19:46:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!t-online.de!skynet.be!skynet.be!freenix!enst!enst.fr!not-for-mail From: "Steven Deller" Newsgroups: comp.lang.ada Subject: RE: Server - tasking and long lived connections Date: Sun, 16 Dec 2001 22:43:23 -0500 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: avanie.enst.fr 1008560762 18434 137.194.161.2 (17 Dec 2001 03:46:02 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Mon, 17 Dec 2001 03:46:02 +0000 (UTC) To: Return-Path: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20011215175619.80358.qmail@web13002.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:17977 Date: 2001-12-16T22:43:23-05:00 In the early 90's I consulted on a system that created more that 10,000 tasks in Ada. The problem was that each task used 100KB of stack and the 1GB of memory just for stack meant they could not load the application. That was solved by making a few more tasks, each for the "computational" aspects of the problem. The "computation" tasks had 100KB or more for their stack. The 10,000 "interface" tasks wre then able to operate with only 5KB of stack -- virtually no "depth" to calls. The "interface" tasks simply collected data (asynchronously) then rendezvous'ed with one or more computational tasks to actually process the data. Besides allowing the application to fit in memory, the transformation also improved throughput by more than 2x because only the computational tasks used floating point so task switching often did not have to save and reload floating point registers. Such a transformation might be feasible for your application so if you can control the stack size of tasks with your chosen compiler and OS, then likely the only limit would be some artificial OS limit on the number of threads per process. Regards, Steven Deller > -----Original Message----- > From: comp.lang.ada-admin@ada.eu.org > [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Eric Merritt > Sent: Saturday, December 15, 2001 12:56 PM > To: comp.lang.ada@ada.eu.org > Subject: Re: Server - tasking and long lived connections > > > > How many parallel connections do you want to handle? > > Is data > > transferred continuously? Does your database > > backend support so many > > client connections? > > Data transfer : There will probably be small data > transfers on the order of tens or hundreds of bytes > more or less continuously. > > Parallel Connections : thirty or forty probably at the > lowest end, as many as passable at the highest end. > > I realize that range is vague, I am pretty sure that > if the number of connections is very high then I will > inevitably have to go to a multiple server approach. My goal > in this case is to delay that as long as possible. Efficiency > is a goal in and of itself as well.