Return-Path: Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: (qmail 40896 invoked from network); 14 Feb 2008 07:35:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Feb 2008 07:35:51 -0000 Received: (qmail 49961 invoked by uid 500); 14 Feb 2008 07:35:44 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 49932 invoked by uid 500); 14 Feb 2008 07:35:44 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 49923 invoked by uid 99); 14 Feb 2008 07:35:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2008 23:35:44 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rajdavies@gmail.com designates 64.233.182.185 as permitted sender) Received: from [64.233.182.185] (HELO nf-out-0910.google.com) (64.233.182.185) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Feb 2008 07:35:11 +0000 Received: by nf-out-0910.google.com with SMTP id b21so178641nfd.16 for ; Wed, 13 Feb 2008 23:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=mVaBgNpzA5WnI4nCRfvOoqwHzpNsYVDyW8VpstqGatU=; b=qLH6U55P+Iw7EMpOQ+cyJHhHGrPocwNtAAo+wR5m5Ko+DPnmk+daPkbALxsfnNrEVlkMG46J4B39skgXbt/Xvo2qf9YCOyyGAQEaC23EmikEpkylRH9CW8TRrmp5V+EXU2bGUx7qyeBIoMOcw3uNQ174IPCQDSJ7oAUmfS2c/uU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=t+hh+3L8rE4P9w5XIqzz5Ea2be9w59Jxrlons0SZhHTFXd70tQiq+lmKzkTQxb/w1SZxGTFpg+IpdwjIaj2Xtn6e+AEMNLepmy1/SFeneB3I38ZJ8FphoHniOReXFb/aWxvLMImgHFvpMy368jszJuD/qyAyTp3QspCziEJXGAw= Received: by 10.78.192.20 with SMTP id p20mr209356huf.40.1202974518626; Wed, 13 Feb 2008 23:35:18 -0800 (PST) Received: from ?192.168.1.64? ( [86.161.176.21]) by mx.google.com with ESMTPS id i8sm4899569nfh.1.2008.02.13.23.35.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Feb 2008 23:35:17 -0800 (PST) Message-Id: From: Rob Davies To: dev@activemq.apache.org In-Reply-To: <47B3B0C4.4070004@nuix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Optimising PrefetchSubscription.dispatchPending() ideas Date: Thu, 14 Feb 2008 07:35:16 +0000 References: <47AC8D46.7060009@nuix.com> <47B13E2C.8060602@nuix.com> <47B28C8C.70707@nuix.com> <5a56ce1b0802131027x79dbdb8dx9fc9949028fe71f0@mail.gmail.com> <47B3B0C4.4070004@nuix.com> X-Mailer: Apple Mail (2.915) X-Virus-Checked: Checked by ClamAV on apache.org On Feb 14, 2008, at 3:08 AM, David Sitsky wrote: > Rob and I did some performance enhancements with queues so that a > Queue.send() call was decoupled from the dispatch processing. In > the past, depending on the state of the consumers, a Queue.send() > call could take a significant amount of time. We changed it so that > a single thread was responsible for dispatching messages, which > avoided a lot of lock contention. It also meant a Queue.send() > returned as quickly as possible. > > I imagine a similar change could be done for Topics, since from what > I can tell, a Topic.send() call currently does its dispatch > processing in the same call. > > Cheers, > David > > Jim Gomes wrote: >> I am very interested in this set of changes. I am currently >> load/performance testing ActiveMQ, and am very surprised at the >> results. >> Anything that can be done to speed this area is a good thing. I >> have found >> a dramatic drop in performance when adding even a single consumer, >> especially to a Topic. The producer to the Topic is slowed down >> quite a >> bit, which was a surprise to me. I expected that the >> existence/non-existence or performance of a consumer would have no >> impact on >> a producer, but that is not the case. A producer is directly >> impacted by >> any consumers, especially idle consumers. An idle Topic consumer can >> actually cause a producer to block. As far as I have been able to >> determine >> from browsing the documentation, this is by design. >> I am looking forward to your efforts in this area. >> Best Regards, >> Jim > > -- > Cheers, > David > > Nuix Pty Ltd > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 > 0699 > Web: http://www.nuix.com Fax: +61 2 9212 > 6902 Yes - Topics next! cheers, Rob