liqiangz commented on issue #6210:
URL: https://github.com/apache/skywalking/issues/6210#issuecomment-965959965


   Now the interface provided by MeterReportService is One period data through 
one stream. There is no problem with a small amount of data as the agent. 
However, when a large amount of data is transmitted from the server to the 
server, the overhead of frequently creating streams is very large.
   
   Maybe we can provide a encapsulated request like opencensus, so that we can 
use keep-alive-stream to improve performance.
   
   The follow is the benchmark in 
https://github.com/liqiangz/opentelemetry-collector-contrib/blob/log-3/exporter/skywalkingexporter/skywalking_benchmark_test.go
   
   ```
   keep alive stream
   The number of goroutines:1,  The number of streams:1,  Sent: 10000 items 
(196/millisecond),  Receive: 10000 items (192/millisecond)
   The number of goroutines:2,  The number of streams:2,  Sent: 10000 items 
(294/millisecond),  Receive: 10000 items (285/millisecond)
   The number of goroutines:4,  The number of streams:4,  Sent: 10000 items 
(357/millisecond),  Receive: 10000 items (357/millisecond)
   The number of goroutines:5,  The number of streams:5,  Sent: 10000 items 
(434/millisecond),  Receive: 10000 items (434/millisecond)
   The number of goroutines:10,  The number of streams:10,  Sent: 10000 items 
(476/millisecond),  Receive: 10000 items (416/millisecond)
   
   One stream One Request
   The number of goroutines:1,  Sent: 10000 items (2/millisecond),  Receive: 
10000 items (2/millisecond)
   The number of goroutines:2,  Sent: 10000 items (5/millisecond),  Receive: 
10000 items (5/millisecond)
   The number of goroutines:4,  Sent: 10000 items (15/millisecond),  Receive: 
10000 items (15/millisecond)
   The number of goroutines:5,  Sent: 10000 items (18/millisecond),  Receive: 
10000 items (18/millisecond)
   The number of goroutines:10,  Sent: 10000 items (40/millisecond),  Receive: 
10000 items (40/millisecond)
   ```
   
   and opencensus proto
   
   ```
   // Service that can be used to push metrics between one Application
   // instrumented with OpenCensus and an agent, or between an agent and a
   // central collector.
   service MetricsService {
     // For performance reasons, it is recommended to keep this RPC
     // alive for the entire life of the application.
     rpc Export(stream ExportMetricsServiceRequest) returns (stream 
ExportMetricsServiceResponse) {}
   }
   
   message ExportMetricsServiceRequest {
     // This is required only in the first message on the stream or if the
     // previous sent ExportMetricsServiceRequest message has a different Node 
(e.g.
     // when the same RPC is used to send Metrics from multiple Applications).
     opencensus.proto.agent.common.v1.Node node = 1;
   
     // A list of metrics that belong to the last received Node.
     repeated opencensus.proto.metrics.v1.Metric metrics = 2;
   
     // The resource for the metrics in this message that do not have an 
explicit
     // resource set.
     // If unset, the most recently set resource in the RPC stream applies. It 
is
     // valid to never be set within a stream, e.g. when no resource info is 
known
     // at all or when all sent metrics have an explicit resource set.
     opencensus.proto.resource.v1.Resource resource = 3;
   }
   
   message ExportMetricsServiceResponse {
   }
   ```
   
   @wu-sheng @kezhenxu94 @mrproliu Could you please give some suggestions about 
this?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to