You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Vikrant Singh <vi...@gmail.com> on 2015/09/16 01:30:30 UTC
tree cache load time
Hello All,
I am using tree cache for one of my project. Issue I am facing is with the
time it is taking for initialize itself. It is taking around 300ms to 3-4 s
to load itself.
This is how I am initializing the client and cache
* private val client = CuratorFrameworkFactory.newClient(hostList, new
ExponentialBackoffRetry(ZookeeperCache.RetryInterval.toMillis.toInt,ZookeeperCache.RetryCount))*
*val cache = TreeCache.newBuilder(client, path).build()*
post this I register for a handler and then wait for
"TreeCacheEvent.Type.INITIALIZED" event. It take on avg 300ms to 3-4 s.
IS there something I can do to improve this performance?
Thanks,
Vikrant
Re: tree cache load time
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
How would you do multiple levels? Maybe I'm missing something, but don't you need to know the names of the child nodes for a level before you can query the level below that?
Oh, that’s true.
On September 15, 2015 at 6:59:46 PM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:
How would you do multiple levels? Maybe I'm missing something, but don't you need to know the names of the child nodes for a level before you can query the level below that?
On Wed, Sep 16, 2015 at 9:58 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
You could even do multiple levels. Of course, you’d run into the 1MB limit at some point. But, maybe if TreeCache knows it needs to do a certain amount of work it could batch it via multi-transaction.
On September 15, 2015 at 6:57:36 PM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:
So you could execute the all the required getChildren calls for a particular level of the tree in a single call to ZK?
On Wed, Sep 16, 2015 at 9:54 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
However, there is an optimization opportunity by using ZK’s multi-transactions. Maybe we can explore this.
-Jordan
On September 15, 2015 at 6:44:46 PM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:
It would be largely dependent upon how much data you're caching. The tree cache needs to recursively query ZK to populate the cache.
cheers
On Wed, Sep 16, 2015 at 9:30 AM, Vikrant Singh <vi...@gmail.com> wrote:
Hello All,
I am using tree cache for one of my project. Issue I am facing is with the time it is taking for initialize itself. It is taking around 300ms to 3-4 s to load itself.
This is how I am initializing the client and cache
private val client = CuratorFrameworkFactory.newClient(hostList, new ExponentialBackoffRetry(ZookeeperCache.RetryInterval.toMillis.toInt,ZookeeperCache.RetryCount))
val cache = TreeCache.newBuilder(client, path).build()
post this I register for a handler and then wait for "TreeCacheEvent.Type.INITIALIZED" event. It take on avg 300ms to 3-4 s.
IS there something I can do to improve this performance?
Thanks,
Vikrant
Re: tree cache load time
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Curator is just a wrapper around the ZooKeeper native client. So, it relies on its algorithm. But, we might be able to write our own pipeline. I’ll have to think about how that would work though. In any event, ZK writes are always ordered so there’s no way to not have them be serialized unless you use multiple sessions (which would be an option I guess).
-JZ
On September 16, 2015 at 1:41:54 PM, Scott Blum (dragonsinth@gmail.com) wrote:
I can't think of any reason Curator's async operations shouldn't work this way.
Re: tree cache load time
Posted by Scott Blum <dr...@gmail.com>.
When I was dealing with Redis a lot, there was a concept of a command
pipeline. It was really a client-side only construct, what it meant is you
could shove a series of commands over the wire without waiting for a
response, and the server would respond in order. So instead of this:
GET ->
<- result 1
PUT ->
<- result 2
EXPIRE ->
<- result 3
As long as your operations didn't depend on each other, you could just do
this:
GET ->
PUT ->
EXPIRE ->
<- result 1
<- result 2
<- result 3
You're just shoving multiple requests over the wire in order without
waiting for any responses, then when the responses come back, you handle
them in order. I can't think of any reason Curator's async operations
shouldn't work this way.
On Wed, Sep 16, 2015 at 1:41 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> I know that the async operation responses in Zk are single threaded and
> that, on the server, ZK needs to maintain order of operations. This is why
> I was thinking the multi-transactions might help.
>
> -JZ
>
>
>
> On September 16, 2015 at 12:34:14 PM, Scott Blum (dragonsinth@gmail.com)
> wrote:
>
> How does that stuff work there?
>
>
Re: tree cache load time
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I know that the async operation responses in Zk are single threaded and that, on the server, ZK needs to maintain order of operations. This is why I was thinking the multi-transactions might help.
-JZ
On September 16, 2015 at 12:34:14 PM, Scott Blum (dragonsinth@gmail.com) wrote:
How does that stuff work there?
Re: tree cache load time
Posted by Scott Blum <dr...@gmail.com>.
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’ll think about it.
>>
>
>
Re: tree cache load time
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <jo...@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’ll think about it.
Re: tree cache load time
Posted by Vikrant Singh <vi...@gmail.com>.
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’ll think about it.
>
Re: tree cache load time
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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’ll think about it.
Re: tree cache load time
Posted by Cameron McKenzie <mc...@gmail.com>.
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.
How much data are you actually caching? Jordan's suggestion of using the
multi transactions is certainly a good one and would provide some
performance benefits, but I have no idea how much.
On Wed, Sep 16, 2015 at 10:06 AM, Vikrant Singh <vikrant.subscribe@gmail.com
> wrote:
> So does this mean I should try to modify tree cache to do multi
> transaction? I was wondering if this is something I can do on top of stock
> tree cache? if yes .. any pointers on how?
>
> On Tue, Sep 15, 2015 at 4:59 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
>> How would you do multiple levels? Maybe I'm missing something, but don't
>> you need to know the names of the child nodes for a level before you can
>> query the level below that?
>>
>> On Wed, Sep 16, 2015 at 9:58 AM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>> You could even do multiple levels. Of course, you’d run into the 1MB
>>> limit at some point. But, maybe if TreeCache knows it needs to do a certain
>>> amount of work it could batch it via multi-transaction.
>>>
>>>
>>> On September 15, 2015 at 6:57:36 PM, Cameron McKenzie (
>>> mckenzie.cam@gmail.com) wrote:
>>>
>>> So you could execute the all the required getChildren calls for a
>>> particular level of the tree in a single call to ZK?
>>>
>>> On Wed, Sep 16, 2015 at 9:54 AM, Jordan Zimmerman <
>>> jordan@jordanzimmerman.com> wrote:
>>>
>>>> However, there is an optimization opportunity by using ZK’s
>>>> multi-transactions. Maybe we can explore this.
>>>>
>>>> -Jordan
>>>>
>>>>
>>>>
>>>> On September 15, 2015 at 6:44:46 PM, Cameron McKenzie (
>>>> mckenzie.cam@gmail.com) wrote:
>>>>
>>>> It would be largely dependent upon how much data you're caching. The
>>>> tree cache needs to recursively query ZK to populate the cache.
>>>> cheers
>>>>
>>>> On Wed, Sep 16, 2015 at 9:30 AM, Vikrant Singh <
>>>> vikrant.subscribe@gmail.com> wrote:
>>>>
>>>>> Hello All,
>>>>> I am using tree cache for one of my project. Issue I am facing is with
>>>>> the time it is taking for initialize itself. It is taking around 300ms to
>>>>> 3-4 s to load itself.
>>>>> This is how I am initializing the client and cache
>>>>>
>>>>>
>>>>> * private val client = CuratorFrameworkFactory.newClient(hostList, new
>>>>> ExponentialBackoffRetry(ZookeeperCache.RetryInterval.toMillis.toInt,ZookeeperCache.RetryCount))*
>>>>>
>>>>>
>>>>> *val cache = TreeCache.newBuilder(client, path).build()*
>>>>>
>>>>>
>>>>> post this I register for a handler and then wait for
>>>>> "TreeCacheEvent.Type.INITIALIZED" event. It take on avg 300ms to 3-4 s.
>>>>> IS there something I can do to improve this performance?
>>>>> Thanks,
>>>>> Vikrant
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: tree cache load time
Posted by Scott Blum <dr...@gmail.com>.
How big of a tree are you grabbing? You might be able to make it go faster
with depth limiting if you don't need the entire tree. Some friends of
mine are using one tree cache with a limited depth at a high level, then
ignoring the parts of the tree they don't care about and making sub-tree
caches that start lower down selectively.
On Tue, Sep 15, 2015 at 8:06 PM, Vikrant Singh <vi...@gmail.com>
wrote:
> So does this mean I should try to modify tree cache to do multi
> transaction? I was wondering if this is something I can do on top of stock
> tree cache? if yes .. any pointers on how?
>
> On Tue, Sep 15, 2015 at 4:59 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
>> How would you do multiple levels? Maybe I'm missing something, but don't
>> you need to know the names of the child nodes for a level before you can
>> query the level below that?
>>
>> On Wed, Sep 16, 2015 at 9:58 AM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>> You could even do multiple levels. Of course, you’d run into the 1MB
>>> limit at some point. But, maybe if TreeCache knows it needs to do a certain
>>> amount of work it could batch it via multi-transaction.
>>>
>>>
>>> On September 15, 2015 at 6:57:36 PM, Cameron McKenzie (
>>> mckenzie.cam@gmail.com) wrote:
>>>
>>> So you could execute the all the required getChildren calls for a
>>> particular level of the tree in a single call to ZK?
>>>
>>> On Wed, Sep 16, 2015 at 9:54 AM, Jordan Zimmerman <
>>> jordan@jordanzimmerman.com> wrote:
>>>
>>>> However, there is an optimization opportunity by using ZK’s
>>>> multi-transactions. Maybe we can explore this.
>>>>
>>>> -Jordan
>>>>
>>>>
>>>>
>>>> On September 15, 2015 at 6:44:46 PM, Cameron McKenzie (
>>>> mckenzie.cam@gmail.com) wrote:
>>>>
>>>> It would be largely dependent upon how much data you're caching. The
>>>> tree cache needs to recursively query ZK to populate the cache.
>>>> cheers
>>>>
>>>> On Wed, Sep 16, 2015 at 9:30 AM, Vikrant Singh <
>>>> vikrant.subscribe@gmail.com> wrote:
>>>>
>>>>> Hello All,
>>>>> I am using tree cache for one of my project. Issue I am facing is with
>>>>> the time it is taking for initialize itself. It is taking around 300ms to
>>>>> 3-4 s to load itself.
>>>>> This is how I am initializing the client and cache
>>>>>
>>>>>
>>>>> * private val client = CuratorFrameworkFactory.newClient(hostList, new
>>>>> ExponentialBackoffRetry(ZookeeperCache.RetryInterval.toMillis.toInt,ZookeeperCache.RetryCount))*
>>>>>
>>>>>
>>>>> *val cache = TreeCache.newBuilder(client, path).build()*
>>>>>
>>>>>
>>>>> post this I register for a handler and then wait for
>>>>> "TreeCacheEvent.Type.INITIALIZED" event. It take on avg 300ms to 3-4 s.
>>>>> IS there something I can do to improve this performance?
>>>>> Thanks,
>>>>> Vikrant
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: tree cache load time
Posted by Vikrant Singh <vi...@gmail.com>.
So does this mean I should try to modify tree cache to do multi
transaction? I was wondering if this is something I can do on top of stock
tree cache? if yes .. any pointers on how?
On Tue, Sep 15, 2015 at 4:59 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> How would you do multiple levels? Maybe I'm missing something, but don't
> you need to know the names of the child nodes for a level before you can
> query the level below that?
>
> On Wed, Sep 16, 2015 at 9:58 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> You could even do multiple levels. Of course, you’d run into the 1MB
>> limit at some point. But, maybe if TreeCache knows it needs to do a certain
>> amount of work it could batch it via multi-transaction.
>>
>>
>> On September 15, 2015 at 6:57:36 PM, Cameron McKenzie (
>> mckenzie.cam@gmail.com) wrote:
>>
>> So you could execute the all the required getChildren calls for a
>> particular level of the tree in a single call to ZK?
>>
>> On Wed, Sep 16, 2015 at 9:54 AM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>> However, there is an optimization opportunity by using ZK’s
>>> multi-transactions. Maybe we can explore this.
>>>
>>> -Jordan
>>>
>>>
>>>
>>> On September 15, 2015 at 6:44:46 PM, Cameron McKenzie (
>>> mckenzie.cam@gmail.com) wrote:
>>>
>>> It would be largely dependent upon how much data you're caching. The
>>> tree cache needs to recursively query ZK to populate the cache.
>>> cheers
>>>
>>> On Wed, Sep 16, 2015 at 9:30 AM, Vikrant Singh <
>>> vikrant.subscribe@gmail.com> wrote:
>>>
>>>> Hello All,
>>>> I am using tree cache for one of my project. Issue I am facing is with
>>>> the time it is taking for initialize itself. It is taking around 300ms to
>>>> 3-4 s to load itself.
>>>> This is how I am initializing the client and cache
>>>>
>>>>
>>>> * private val client = CuratorFrameworkFactory.newClient(hostList, new
>>>> ExponentialBackoffRetry(ZookeeperCache.RetryInterval.toMillis.toInt,ZookeeperCache.RetryCount))*
>>>>
>>>>
>>>> *val cache = TreeCache.newBuilder(client, path).build()*
>>>>
>>>>
>>>> post this I register for a handler and then wait for
>>>> "TreeCacheEvent.Type.INITIALIZED" event. It take on avg 300ms to 3-4 s.
>>>> IS there something I can do to improve this performance?
>>>> Thanks,
>>>> Vikrant
>>>>
>>>>
>>>>
>>>
>>
>
Re: tree cache load time
Posted by Cameron McKenzie <mc...@gmail.com>.
How would you do multiple levels? Maybe I'm missing something, but don't
you need to know the names of the child nodes for a level before you can
query the level below that?
On Wed, Sep 16, 2015 at 9:58 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> You could even do multiple levels. Of course, you’d run into the 1MB limit
> at some point. But, maybe if TreeCache knows it needs to do a certain
> amount of work it could batch it via multi-transaction.
>
>
> On September 15, 2015 at 6:57:36 PM, Cameron McKenzie (
> mckenzie.cam@gmail.com) wrote:
>
> So you could execute the all the required getChildren calls for a
> particular level of the tree in a single call to ZK?
>
> On Wed, Sep 16, 2015 at 9:54 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> However, there is an optimization opportunity by using ZK’s
>> multi-transactions. Maybe we can explore this.
>>
>> -Jordan
>>
>>
>>
>> On September 15, 2015 at 6:44:46 PM, Cameron McKenzie (
>> mckenzie.cam@gmail.com) wrote:
>>
>> It would be largely dependent upon how much data you're caching. The tree
>> cache needs to recursively query ZK to populate the cache.
>> cheers
>>
>> On Wed, Sep 16, 2015 at 9:30 AM, Vikrant Singh <
>> vikrant.subscribe@gmail.com> wrote:
>>
>>> Hello All,
>>> I am using tree cache for one of my project. Issue I am facing is with
>>> the time it is taking for initialize itself. It is taking around 300ms to
>>> 3-4 s to load itself.
>>> This is how I am initializing the client and cache
>>>
>>>
>>> * private val client = CuratorFrameworkFactory.newClient(hostList, new
>>> ExponentialBackoffRetry(ZookeeperCache.RetryInterval.toMillis.toInt,ZookeeperCache.RetryCount))*
>>>
>>>
>>> *val cache = TreeCache.newBuilder(client, path).build()*
>>>
>>>
>>> post this I register for a handler and then wait for
>>> "TreeCacheEvent.Type.INITIALIZED" event. It take on avg 300ms to 3-4 s.
>>> IS there something I can do to improve this performance?
>>> Thanks,
>>> Vikrant
>>>
>>>
>>>
>>
>
Re: tree cache load time
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
You could even do multiple levels. Of course, you’d run into the 1MB limit at some point. But, maybe if TreeCache knows it needs to do a certain amount of work it could batch it via multi-transaction.
On September 15, 2015 at 6:57:36 PM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:
So you could execute the all the required getChildren calls for a particular level of the tree in a single call to ZK?
On Wed, Sep 16, 2015 at 9:54 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
However, there is an optimization opportunity by using ZK’s multi-transactions. Maybe we can explore this.
-Jordan
On September 15, 2015 at 6:44:46 PM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:
It would be largely dependent upon how much data you're caching. The tree cache needs to recursively query ZK to populate the cache.
cheers
On Wed, Sep 16, 2015 at 9:30 AM, Vikrant Singh <vi...@gmail.com> wrote:
Hello All,
I am using tree cache for one of my project. Issue I am facing is with the time it is taking for initialize itself. It is taking around 300ms to 3-4 s to load itself.
This is how I am initializing the client and cache
private val client = CuratorFrameworkFactory.newClient(hostList, new ExponentialBackoffRetry(ZookeeperCache.RetryInterval.toMillis.toInt,ZookeeperCache.RetryCount))
val cache = TreeCache.newBuilder(client, path).build()
post this I register for a handler and then wait for "TreeCacheEvent.Type.INITIALIZED" event. It take on avg 300ms to 3-4 s.
IS there something I can do to improve this performance?
Thanks,
Vikrant
Re: tree cache load time
Posted by Cameron McKenzie <mc...@gmail.com>.
So you could execute the all the required getChildren calls for a
particular level of the tree in a single call to ZK?
On Wed, Sep 16, 2015 at 9:54 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> However, there is an optimization opportunity by using ZK’s
> multi-transactions. Maybe we can explore this.
>
> -Jordan
>
>
>
> On September 15, 2015 at 6:44:46 PM, Cameron McKenzie (
> mckenzie.cam@gmail.com) wrote:
>
> It would be largely dependent upon how much data you're caching. The tree
> cache needs to recursively query ZK to populate the cache.
> cheers
>
> On Wed, Sep 16, 2015 at 9:30 AM, Vikrant Singh <
> vikrant.subscribe@gmail.com> wrote:
>
>> Hello All,
>> I am using tree cache for one of my project. Issue I am facing is with
>> the time it is taking for initialize itself. It is taking around 300ms to
>> 3-4 s to load itself.
>> This is how I am initializing the client and cache
>>
>>
>> * private val client = CuratorFrameworkFactory.newClient(hostList, new
>> ExponentialBackoffRetry(ZookeeperCache.RetryInterval.toMillis.toInt,ZookeeperCache.RetryCount))*
>>
>>
>> *val cache = TreeCache.newBuilder(client, path).build()*
>>
>>
>> post this I register for a handler and then wait for
>> "TreeCacheEvent.Type.INITIALIZED" event. It take on avg 300ms to 3-4 s.
>> IS there something I can do to improve this performance?
>> Thanks,
>> Vikrant
>>
>>
>>
>
Re: tree cache load time
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
However, there is an optimization opportunity by using ZK’s multi-transactions. Maybe we can explore this.
-Jordan
On September 15, 2015 at 6:44:46 PM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:
It would be largely dependent upon how much data you're caching. The tree cache needs to recursively query ZK to populate the cache.
cheers
On Wed, Sep 16, 2015 at 9:30 AM, Vikrant Singh <vi...@gmail.com> wrote:
Hello All,
I am using tree cache for one of my project. Issue I am facing is with the time it is taking for initialize itself. It is taking around 300ms to 3-4 s to load itself.
This is how I am initializing the client and cache
private val client = CuratorFrameworkFactory.newClient(hostList, new ExponentialBackoffRetry(ZookeeperCache.RetryInterval.toMillis.toInt,ZookeeperCache.RetryCount))
val cache = TreeCache.newBuilder(client, path).build()
post this I register for a handler and then wait for "TreeCacheEvent.Type.INITIALIZED" event. It take on avg 300ms to 3-4 s.
IS there something I can do to improve this performance?
Thanks,
Vikrant
Re: tree cache load time
Posted by Cameron McKenzie <mc...@gmail.com>.
It would be largely dependent upon how much data you're caching. The tree
cache needs to recursively query ZK to populate the cache.
cheers
On Wed, Sep 16, 2015 at 9:30 AM, Vikrant Singh <vi...@gmail.com>
wrote:
> Hello All,
> I am using tree cache for one of my project. Issue I am facing is with the
> time it is taking for initialize itself. It is taking around 300ms to 3-4 s
> to load itself.
> This is how I am initializing the client and cache
>
>
> * private val client = CuratorFrameworkFactory.newClient(hostList, new
> ExponentialBackoffRetry(ZookeeperCache.RetryInterval.toMillis.toInt,ZookeeperCache.RetryCount))*
>
>
> *val cache = TreeCache.newBuilder(client, path).build()*
>
>
> post this I register for a handler and then wait for
> "TreeCacheEvent.Type.INITIALIZED" event. It take on avg 300ms to 3-4 s.
> IS there something I can do to improve this performance?
> Thanks,
> Vikrant
>
>
>