Return-Path: X-Original-To: apmail-curator-user-archive@minotaur.apache.org Delivered-To: apmail-curator-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5B35818F1D for ; Wed, 16 Sep 2015 17:34:14 +0000 (UTC) Received: (qmail 37713 invoked by uid 500); 16 Sep 2015 17:34:14 -0000 Delivered-To: apmail-curator-user-archive@curator.apache.org Received: (qmail 37670 invoked by uid 500); 16 Sep 2015 17:34:14 -0000 Mailing-List: contact user-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@curator.apache.org Delivered-To: mailing list user@curator.apache.org Received: (qmail 37660 invoked by uid 99); 16 Sep 2015 17:34:14 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Sep 2015 17:34:14 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id C2CB4180976 for ; Wed, 16 Sep 2015 17:34:13 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.899 X-Spam-Level: *** X-Spam-Status: No, score=3.899 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id XrZlZLIMTR5H for ; Wed, 16 Sep 2015 17:34:06 +0000 (UTC) Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 79B5C44569 for ; Wed, 16 Sep 2015 17:34:06 +0000 (UTC) Received: by ykft14 with SMTP id t14so74712217ykf.0 for ; Wed, 16 Sep 2015 10:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r4MSJors8dP5h47xAO7SNjgRfNrV5N6s1AbJ8jxwM5I=; b=eNAZJRbmjnzSPKnd+7Z3dPTspivGC6ZSjmp68cEqYpJNRgaWCx6esy3gOo6gghc0MS 6fTc48GSj3x4POJ2yg/n8q6WKwTkItCXJY1sKEWBIWvKCFNv54bZ3dR++RWxoaIsiQd7 vcO8x2cqz+ZOHucgsQ9rS0vhnYl+wuPynrRIBCfRaBjGcTd/wCagM9+w0ll2TfDxLLTC o9MltpSJgU1h3CjA/jvd7kW4Z4jCBXOgUQ4JjYN51AKhWDniNYHFINH6UuMvekc+HQSq 9GzlW34wf83O5L1VQgNveCkj9d2WjFVSsK3luE4oOzcljr/Mu3z7cJeRKBj1Usqf8L3Y ITig== MIME-Version: 1.0 X-Received: by 10.129.106.194 with SMTP id f185mr28441916ywc.21.1442424840012; Wed, 16 Sep 2015 10:34:00 -0700 (PDT) Received: by 10.37.80.150 with HTTP; Wed, 16 Sep 2015 10:33:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Sep 2015 13:33:59 -0400 Message-ID: Subject: Re: tree cache load time From: Scott Blum To: user@curator.apache.org Cc: Vikrant Singh Content-Type: multipart/alternative; boundary=001a11473c18344cc8051fe0b4cb --001a11473c18344cc8051fe0b4cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Vikrant, how much latency is between you and the server? I doubt fork join would help at all, I'm sure the latency is successive server round trips. I thought TreeCache was already pretty decent on that front, because we use the async version of every call. I assumed doing that would allow me to "pipeline" server requests and react as each response came back. But it occurs to me that the connection might actually be blocking per request under the hood. How does that stuff work there? On Wed, Sep 16, 2015 at 12:53 PM, Jordan Zimmerman < jordan@jordanzimmerman.com> wrote: > Another idea would be to modify TreeCache to use fork/join. I may be > overthinking things here. > > -JZ > > > > On September 16, 2015 at 11:52:07 AM, Vikrant Singh ( > vikrant.subscribe@gmail.com) wrote: > > Tree is not quite big.. it is only 4 level.. .and nodes on 3rd level will > have only 1 child node. > I am interested only in monitoring 3 & 4 level.. 1 & 2 will never change. > > Even after changing the MaxDepth (from default to 3) i do not see much > performance gain. > > Any advise to get some performance here? > > On Tue, Sep 15, 2015 at 7:37 PM, Jordan Zimmerman < > jordan@jordanzimmerman.com> wrote: > >> I don't think you'll be able to extend the existing TreeCache to handle >> multi transactions. It would need to be a modification within Curator. >> >> >> Hmm - that might be a nice feature. I=E2=80=99ll think about it. >> > > --001a11473c18344cc8051fe0b4cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Vikrant, how much latency is between you and the server?
I doubt fork join would help at all, I'm sure the lat= ency is successive server round trips.=C2=A0 I thought TreeCache was alread= y pretty decent on that front, because we use the async version of every ca= ll.=C2=A0 I assumed doing that would allow me to "pipeline" serve= r requests and react as each response came back.=C2=A0 But it occurs to me = that the connection might actually be blocking per request under the hood.= =C2=A0 How does that stuff work there?


On Wed, Sep 16, 2015 at 12:= 53 PM, Jordan Zimmerman <jordan@jordanzimmerman.com> wrote:
Another idea would be to modify TreeCa= che to use fork/join. I may be overthinking things here.

-JZ
<= div class=3D"h5">


On September 16, 201= 5 at 11:52:07 AM, Vikrant Singh (vikrant.subscribe@gmail.com) wrote:

Tree is not quite big.. it is only 4 level.. .and nodes on 3rd level will have only 1 child node.=C2=A0
I am interested only in monitoring 3 & 4 level.. 1 & 2 will never change.

Even after changing the MaxDepth (from default to 3) i do not see much performance gain.

Any advise to get some performance here?

On Tue, Sep 15, 2015 at 7:37 PM, Jordan Zimmerman <jordan@jordanzimmerman.com> wrote:
I don't think you'll be able to extend the existing TreeCache to handle multi transactions. It would need to be a modification within Curator.


Hmm - that might be a nice feature. I=E2=80=99ll think about it.


--001a11473c18344cc8051fe0b4cb--