infact, we already reduced query response size by 304 NOT MODIFIED only intstances changed, then will send all instances for the query microservice
for big cluster scenes, we can compress response body, i feel that's simple and enough. Zheng Feng <zh.f...@gmail.com> 于2018年11月9日周五 上午10:50写道: > So the question is how the server knows the differences with the client > request from the last time ? there are snapshots in the SC with every > instance status changes ? > > Yang Bo <oaky...@gmail.com> 于2018年11月9日周五 上午9:39写道: > > > How about add some patching mechanisms. The server only send information > of > > changed instances in the query response. > > This will drastically reduce the response size when only a few instances > > changes in a huge cluster. > > > > On Fri, Nov 9, 2018 at 9:15 AM bismy <bi...@qq.com> wrote: > > > > > I think we need take more considerations on how users use this API. > > > According to what we have done, server side need to cache all query > > > results. We can't just say 'We just let the client to find out what > they > > > want to know' and leave all things to users, because the most important > > > part of instance management is how to keep data consistence both on > > server > > > side and client side. > > > > > > > > > For this problem, I intend to agree with @zzzwjm. We didn't see any > > > critical problem for the current solution to query all possible > > instances. > > > Maybe current solution will have problem with two conditions met: 1. > > > instances is huge; 2. instances up/down very frequently. At this > > > conditions, the provided solution seems not work very good too. > > > > > > > > > ------------------ 原始邮件 ------------------ > > > 发件人: "willem.jiang"<willem.ji...@gmail.com>; > > > 发送时间: 2018年11月9日(星期五) 上午8:50 > > > 收件人: "dev"<dev@servicecomb.apache.org>; > > > > > > 主题: Re: [DISCUSS]Discovery API support filter instances by properties > > > > > > > > > > > > I think Sure is just want SC provide some filtering query on the > > > server side, we don't need to let the server cached all the query > > > result. > > > We just let the client to find out what they want to know, server > > > don't need to send all the data to the client unless the client wants > > > them. > > > > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Fri, Nov 9, 2018 at 5:47 AM wjm wjm <zzz...@gmail.com> wrote: > > > > > > > > that will cause SC cache results by different query parameters, is it > > too > > > > heavy? > > > > > > > > even has 2k instances , but client query by data version, if not > > > changed, > > > > only response 304 NOT MODIFIED > > > > if instances changed, and response size is big, then can response > with > > > > compress > > > > so there is no problem? > > > > > > > > Sure <sure_0...@qq.com> 于2018年11月7日周三 下午11:36写道: > > > > > > > > > > > > > > > https://github.com/apache/incubator-servicecomb-service-center/issues/482 > > > > > > > > > > Hi guys, > > > > > > > > > > Our system has 20+ services, and each service has 2k instances at > > most. > > > > > All the instances are grouped by some labels(in Properties). > > > > > > > > > > We are now querying all the instances from SC, and then filtering > > > them by > > > > > labels on the client side. This wastes a lot of bandwidth and has > > poor > > > > > performance. Can SC's API provide the filtering function? > > > > > > > > > > Thx. > > > > > > > > -- > > Best Regards, > > Yang. > > >