We have C++ GRPC client (at windows) and c++ GRPC server (at Linux) and
like to communicate server using SSL for encrypted transfer of messages.
We have implemented the SSL server and able to communicate to it by
establishing secure channel from client, however the flip side is currently
we ar
Any update on this?
On Friday, September 17, 2021 at 12:10:22 PM UTC+5:30 Sureshbabu Seshadri
wrote:
> Thanks, please find two log files one where DNS resolution failed and
> another one resolved with the help of native value set to GRPC_DNS_RESOLVER
> environment variable in the
Thanks, please find two log files one where DNS resolution failed and
another one resolved with the help of native value set to GRPC_DNS_RESOLVER
environment variable in the following share
https://drive.google.com/file/d/1DbipVJzdvfcLHseSGEuJvZLfJHXsXtUJ/view?usp=sharing
Please let me know if
OK, without GRPC_DNS_RESOLVER it is always reproducible, can you elaborate
which log type to be enabled as GRPC usually writes tons of logs if we
enable ALL.
On Wednesday, September 15, 2021 at 10:41:46 PM UTC+5:30
sanjay...@google.com wrote:
> Which gRPC language are you using? Is it C++? If
In our intranet, GRPC servers are running in different computers. While
many of the servers are connecting without any issue, there are some
servers failed with error *"DNS resolution failed for service :
:"*
The issue can be resolved by adding the environment variable
*GRPC_DNS_RESOLVER* with
t; know what the wire protocol looks like for that, so maybe it's larger?).
>
> I'm sorry that we can't be of more immediate help here. Good luck!
>
>
> On Wed, Sep 8, 2021 at 2:36 AM Sureshbabu Seshadri
> wrote:
>
>> Thanks Mark for some more details.
&
on for your project, but it might be useful to
> understand why. If you can change that, I think you will see significant
> performance wins.
>
> On Sun, Sep 5, 2021 at 9:13 AM Sureshbabu Seshadri
> wrote:
>
>> Hi Mark,
>> Please find GRPC logs with tcp enabled
is
> actually a realistic benchmark for your production workload. You might get
> better performance by parallelizing the requests from the client.
>
> On Fri, Sep 3, 2021 at 2:29 AM Sureshbabu Seshadri
> wrote:
>
>> Thanks Mark. The below link has source code of my sampl
algo is interfering. try
>> disabling nagle and/or running traceroute.
>>
>> On Fri, Sep 3, 2021 at 1:47 PM Sureshbabu Seshadri
>> wrote:
>>
>>> thanks Mark, parallelizing is not an option for my project. As I
>>> initially mentioned this project
zing the requests from the client.
>
> On Fri, Sep 3, 2021 at 2:29 AM Sureshbabu Seshadri
> wrote:
>
>> Thanks Mark. The below link has source code of my sample, please let me
>> know if you need any other information to analyze
>>
>>
>> https://d
so sorry for not responding sooner! For some reason, gmail
> tagged your messages as spam, so I didn't see them. :(
>
> On Fri, Aug 27, 2021 at 10:55 PM Sureshbabu Seshadri
> wrote:
>
>> Dear GRPC team,
>> Can any one help on this?
>>
>> On Friday
Dear GRPC team,
Can any one help on this?
On Friday, August 13, 2021 at 12:53:21 PM UTC+5:30 Sureshbabu Seshadri
wrote:
> Mark,
> Please find the grpc ttrace logs in the following link
> https://drive.google.com/file/d/15y7KzyCtIeAoYSUzyPHpY4gcr7uUnIP0/view?usp=sharing
>
> I
Thursday, August 12, 2021 at 11:27:16 AM UTC+5:30 Sureshbabu Seshadri
wrote:
> Thanks Mark, my current profile does not include channel creation time.
> Profiling is only applicable for RPC calls. We have an existing code base
> for IPC which uses CORBA architecture and we are trying t
Thanks Mark, my current profile does not include channel creation time.
Profiling is only applicable for RPC calls. We have an existing code base
for IPC which uses CORBA architecture and we are trying to replace it with
GRPC, similar sample in CORBA completes quickly that is 1000 RPCs are
comp
:07 MESZ schrieb Jeff Steger :
>>
>> Sounds like network delays. try doing a traceroute to see the paths
>> packets are taking from client to server and their associated delays.
>>
>> https://en.m.wikipedia.org/wiki/Traceroute
>>
>>
>> On Sun, Aug 8,
*Environment*
1. Both client and server are C++
2. Server might be running either locally or in different system
3. In case of remote server, it is in same network.
4. Using SYNC C++ server
5. Unary RPC
Our performance numbers are very low for running 1000 RPC calls (continuous
ca
16 matches
Mail list logo
