Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 63180 invoked from network); 7 Jan 2006 18:36:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Jan 2006 18:36:41 -0000 Received: (qmail 29556 invoked by uid 500); 7 Jan 2006 18:36:40 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 29313 invoked by uid 500); 7 Jan 2006 18:36:39 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 29298 invoked by uid 99); 7 Jan 2006 18:36:39 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Jan 2006 10:36:39 -0800 X-ASF-Spam-Status: No, hits=2.1 required=10.0 tests=MAILTO_TO_SPAM_ADDR,NO_REAL_NAME,RCVD_IN_SORBS_WEB,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of fedechicco@gmail.com designates 64.233.162.199 as permitted sender) Received: from [64.233.162.199] (HELO zproxy.gmail.com) (64.233.162.199) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Jan 2006 10:36:38 -0800 Received: by zproxy.gmail.com with SMTP id i1so3516267nzh for ; Sat, 07 Jan 2006 10:36:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:from:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=dQvaMsBB+68ixs3HBzsaEMoLdrqTrleUP4KxLMI9C1vaI+IQBnsAKf7Yi6qAHjJ0b478H9iazYQss8ar1EvxT8LScwJrPMwLcG/+VmBZW+vurYZguNdgpboU1NVKujGsiEmHqvFSRTqRcYgjKJ18uRs+km7VwKB9btxKVdStRfE= Received: by 10.65.218.9 with SMTP id v9mr2188762qbq; Sat, 07 Jan 2006 10:36:17 -0800 (PST) Received: from fedechiccowinxp ( [213.156.52.114]) by mx.gmail.com with ESMTP id e15sm6357081qba.2006.01.07.10.36.14; Sat, 07 Jan 2006 10:36:17 -0800 (PST) Message-ID: <005901c613b9$3c875f20$0300a8c0@fedechiccowinxp> From: To: "Apache Directory Developers List" References: <768dcb2e0601051929p39fb1541h@mail.gmail.com> <1136595193.25583.0.camel@localhost.localdomain> <20060107101622.rkxxa2qpw6ooo8gk@webmail.daune-consult.com> <43BF88F1.8030103@pandora.be> <43BF9E9C.2070506@bellsouth.net> <000b01c61391$89bb7fb0$0300a8c0@fedechiccowinxp> <43BFFA86.7030902@bellsouth.net> Subject: Re: [MINA] What about a cluster for network load balancing? Date: Sat, 7 Jan 2006 19:36:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N "Alex Karasulu" wrote: > That's neat experiment. I'd be interested in seeing a simple application > and some performance metrics. I think TCP based protocols would most > benefit from this. As I said I have implemented yet a server that use this kind of work, and I can give you the performance of my server right now: I'm running only a single mina program as network-farm (i've called this program "dislocator", and that protocol "dislocation protocol"), but the results are impressive: BandWidth Speed (out): 2,46 Kb/s BandWidth Speed (in): 1,23 Kb/s BandWidth Speed (total): 3,70 Kb/s theese up are the bandwidth usages of the thinking-block and theese down are the bandwidth usages of my single dislocator: Users: 1160 ReadBand: 22,68 Kb/s writeBand: 377,96 Kb/s You can see that there are 1160 users connected to this MINAs dislocator, so many many messages that must be sent to all users (it's a p2p protocol, they are the search messages) are sent from thinking-block to the network-farm only once, than my single dislocator duplicate it 1160 times and resend it over all the sockets. You can see that it work well because this "must-to-be-sent-equal-to-all-the-users" messages are the higher part of the traffic. > I think TCP based protocols would most benefit from this. I agree, actually I've developed it for tcp only, but also UDP can work fine in this way. > > It sounds very interesting. As with many ideas things come down to doing > some experimentation and testing out the theory. I know that for example > SEDA sounds great on paper but can create so many headaches in practice. > Well, I've thought a lot about that project, and I know that it has a principal limitation: it can work fine only for protocol that have a poor CPU usage for protocol elaboration (the network load is divide between many jvms, but all the CPU work is done by the thinking-block), and that it can work well only for protocol like hubs, in wich a message must to be sent over many sockets, or must to be sent the same many times equal (in this case the an adaptive Huffman encode should be fine) Every kind of protocol that do not have theese features will not have any bandwidth advantage from that system, but this kind of protocols are the most diffused chat - gaming - p2p protocols.