yes, zzzwjm, SC is hard to analysis which instances changed for every SDK 
client.


and i have finish the issue about compress the response from sc.
https://github.com/apache/servicecomb-service-center/pull/496


so, Whether we need to do this feature, we can try to test under the current 
mode and get the performance report first.





------------------ ???????? ------------------
??????: "zzzwjm"<[email protected]>;
????????: 2018??11??9??(??????) ????10:54
??????: "dev"<[email protected]>;

????: Re: [DISCUSS]Discovery API support filter instances by properties



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 <[email protected]> ??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 <[email protected]> ??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 <[email protected]> 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"<[email protected]>;
> > > ????????: 2018??11??9??(??????) ????8:50
> > > ??????: "dev"<[email protected]>;
> > >
> > > ????: 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 <[email protected]> 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 <[email protected]> ??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.
> >
>

Reply via email to