Return-Path: X-Original-To: apmail-activemq-users-archive@www.apache.org Delivered-To: apmail-activemq-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E114F784A for ; Mon, 12 Sep 2011 21:48:42 +0000 (UTC) Received: (qmail 44935 invoked by uid 500); 12 Sep 2011 21:48:42 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 44901 invoked by uid 500); 12 Sep 2011 21:48:42 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 44893 invoked by uid 99); 12 Sep 2011 21:48:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Sep 2011 21:48:42 +0000 X-ASF-Spam-Status: No, hits=4.5 required=5.0 tests=HTML_MESSAGE,SPF_SOFTFAIL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: softfail (nike.apache.org: transitioning domain of bhupesh@groupon.com does not designate 216.139.236.26 as permitted sender) Received: from [216.139.236.26] (HELO sam.nabble.com) (216.139.236.26) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Sep 2011 21:48:36 +0000 Received: from joe.nabble.com ([192.168.236.139]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R3EMR-00066G-4w for users@activemq.apache.org; Mon, 12 Sep 2011 14:48:15 -0700 Date: Mon, 12 Sep 2011 14:48:15 -0700 (PDT) From: bbansal To: users@activemq.apache.org Message-ID: In-Reply-To: References: <1315786131978-3806018.post@n4.nabble.com> Subject: Re: Backlog data causes producers to slow down. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_28910_10672567.1315864095144" X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_28910_10672567.1315864095144 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey Gary, I will try to write a testcase but based on my Jprofile it looks to me contention is for write lock due to removeMessages() calls after they receive the ack from the client side and the incoming producer messages. I am going to play with producer-flow-control settings and other configurations mentioned in this thread and report back if I see some significant difference. Best Bhupesh On Mon, Sep 12, 2011 at 9:17 AM, Gary Tully [via ActiveMQ] < ml-node+s2283324n3807858h81@n4.nabble.com> wrote: > on the results of your jprobe profiling, it would be good to identify > if there is a real contention problem there. > If you can generate a simple junit test case that demonstrates the > behavior you are seeing, please open a jira issue and we can > investigate some more. > A test case will help focus the analysis. > > On 12 September 2011 01:08, bbansal <[hidden email]> > wrote: > > > Hello folks, > > > > I am evaluating ActiveMQ for some simple scenarios. The web-server will > push > > notifications to the queue/topic to be consumed by one or many consumers. > > > The one requirement is web-server should not get impacted or should be > able > > to write at their speed even if consumers goes down etc. > > > > ActiveMQ is performing very well with about 1500 QPS (8 producer thread, > > persistence, kaha-db) Kahadb parameters being used are > > > > enableJournalDiskSyncs="false" indexWriteBatchSize="1000" > > enableIndexWriteAsync="true > > > > The system works great if consumers are all caught up, the issue is when > I > > am trying to test scenarios with backlogged data (keep running producer > for > > 30 mins or so) and then start consumers. Consumer show good consumption > rate > > but the producers (8 threads same as before) cannot do more than 120 QPS. > > > This is a drop of more than 90% degradation. > > > > I ran profiler on the code (Jprofiler) and looks like the writers are > > getting stuck for write locks while competing with the > removeAsyncMessages() > > or call to clear messages which got acknowledged from clients etc. > > > > I saw similar complaints for some other folks, Is there some settings we > can > > use to fix the problem ? I dont want to degrade any guarantee level (eg. > > disable acks etc). > > > > Would be more than happy to run experiments with different settings if > folks > > have some suggestions. > > > > > > > > -- > > View this message in context: > http://activemq.2283324.n4.nabble.com/Backlog-data-causes-producers-to-slow-down-tp3806018p3806018.html > > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > > > > > -- > http://fusesource.com > http://blog.garytully.com > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://activemq.2283324.n4.nabble.com/Backlog-data-causes-producers-to-slow-down-tp3806018p3807858.html > To unsubscribe from Backlog data causes producers to slow down., click > here. > > -- View this message in context: http://activemq.2283324.n4.nabble.com/Backlog-data-causes-producers-to-slow-down-tp3806018p3808739.html Sent from the ActiveMQ - User mailing list archive at Nabble.com. ------=_Part_28910_10672567.1315864095144--