I just stumbled over the issue https://github.com/grpc/grpc/pull/5928 and saw that Jan mentioned that it's still not possible but at least more than before.
From my understanding, the client-channel coupling seems to be loose now, but the server seems to still be tightly coupled with the channel, right?
As written in the issue, it seem's to be under discussion if you want to integrate in-process at all. My project would hugely benefit from this functionality due to the performance improvement this brings. (I'm using the same services for internal and external requests).
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/cf638422-d314-4b22-8ae9-9f876944e872%40googlegroups.com.
> The biggest problems with in-process:
> 1. C# protobufs are mutable and therefore passing the messages between client and server by reference is dangerous.
I do understand that. But it should be faster to deep-clone it instead of (de-)serializing it. Or using the serializing to clone it and at least spare the TCP.
> 2. At least one of the possible approaches to implement in-process communication would be to entirely skip interaction with C core, but that can be highly problematic because we would basically need to reimplement the whole stack to ensure the in-process communication would behave the same as the regular communication (and we really don't want to do that).
>
> One thing that could be done is to expose some options to make it possible to use a sockpair or unix domain sockets to communicate between a client and a server. That would still involve serialization and deserialization though.
>
> Can you give some description of the purpose of your application and what seems to be the performance bottleneck for you? We definitely have plans to add more performance optimization for gRPC C#. (E.g. for large messages, there is currently too much copying happening but we have plans to improve that).
I did some tests and it seems that the overhead is around 1000 times for smaller messages (averaged in a test with 10.000 messages, skipped the first message and therefore the connecting time). Localhost only in this test, server and client running in the same process.
Those were the results, also showing the input and output messages:
Test set: Reverse name of Person (only name set)
================================================
Input: { "name": "John Wayne" }
Output: { "name": "enyaW nhoJ" }
================================================
#1
First plain call: 0,2694 ms
Plain method call (avg): 0,0002 ms
First service call: 43,1761 ms
Avarage over 80.000: 0,4029 ms
#2
First plain call: 0,2862 ms
Plain method call (avg): 0,0002 ms
First service call: 43,0379 ms
Avarage over 80.000: 0,4176 ms
#3
First plain call: 0,2851 ms
Plain method call (avg): 0,0003 ms
First service call: 43,6412 ms
Avarage over 80.000: 0,4151 ms
#4 (plain using serialization-copy)
First plain call: 1,2594 ms
Plain method call (avg): 0,0010 ms
First service call: 41,1755 ms
Avarage over 80.000: 0,4804 ms
Test set: Sign configuration with Any TestAllTypes (delay 500 ms)
=================================================================
Input: { "componentName": "UnitTestComp", "serviceName": "UnitTestServ", "signed": { "message": { "@type": "type.googleapis.com/protobuf_unittest.TestAllTypes", "@value": "CGQQsZmd7rldGP////8PIP///////////wEojwcw5b/xvM7OBT0XAAAAQcsE+3EfAQAATYX///9RDtAxjMX0//9dAABEQWEAAAAAAIA3QGgBcg50ZXN0CXdpdGgJdGFic3oEAQIDBJIBAggjmgECCAqiAQIIFKgBAbABBbgBCdIBAgg2+gEDZMgBggIMsZmd7rldy4nsj/cjigIGAP////8PkgILAP///////////wGaAgSPB/YBogIO5b/xvM7OBeS/8bzOzgWqAggXAAAAKgAAALICEMsE+3EfAQAAsUzHnesCAAC6AgiF////QQEAAMICEA7QMYzF9P//scyR10wnAADKAggAAERBw/XIQdICEAAAAAAAgDdAZmZmZmZmRUDaAgIBAOICDnRlc3QJd2l0aAl0YWJz4gIPSnVzdEFub3RoZXJUZXN06gIEAQIDBOoCAIIDAggjggMCCDeKAwIICooDAggUkgMCCBSSAwIICpoDAgECogMCBQaqAwIJB7IDAgg2sgMCCAu6AwQIFhBkugMFCCEQyAHCAw4IsZmd7rldELGZne65XcIDDgjLieyP9yMQy4nsj/cjygMGCP////8PygMGEP////8P0gMLCP///////////wHSAwsQ////////////AdoDBgiPBxCPB9oDBgj2ARD2AeIDEAjlv/G8zs4FEOW/8bzOzgXiAxAI5L/xvM7OBRDkv/G8zs4F6gMKDRYAAAAVFwAAAOoDCg0MAAAAFSoAAADyAxIJywT7cR8BAAARywT7cR8BAADyAxIJsUzHnesCAAARsUzHnesCAAD6AwoNhf///xWF////+gMKDUEBAAAVQQEAAIIEEgkO0DGMxfT//xEO0DGMxfT//4IEEgmxzJHXTCcAABGxzJHXTCcAAIoEBRUAAERBigQHCAEVw/XIQZIECREAAAAAAIA3QJIECwgBEWZmZmZmZkVAmgQCEAGaBAIIAaIEHQoLRmlyc3RTdHJpbmcSDnRlc3QJd2l0aAl0YWJzogQfCgxTZWNvbmRTdHJpbmcSD0p1c3RBbm90aGVyVGVzdKoEBhIEBAMCAaoEAggBsgQEEgIII7IEBggBEgIIN7oEBBICCAq6BAYIARICCBTCBAQSAggUwgQGCAESAggKygQCEAHKBAQIARAC0gQCEAXSBAQIARAG2gQCEAnaBAQIARAH4gQEEgIINuIEBggBEgIICw==" } }, "unsigned": { "message": { "@type": "type.googleapis.com/protobuf_unittest.TestAllTypes", "@value": "CGQQsZmd7rldGP////8PIP///////////wEojwcw5b/xvM7OBT0XAAAAQcsE+3EfAQAATYX///9RDtAxjMX0//9dAABEQWEAAAAAAIA3QGgBcg50ZXN0CXdpdGgJdGFic3oEAQIDBJIBAggjmgECCAqiAQIIFKgBAbABBbgBCdIBAgg2" } } }
Output: { "componentName": "UnitTestComp", "serviceName": "UnitTestServ", "unsigned": { "message": { "@type": "type.googleapis.com/protobuf_unittest.TestAllTypes", "@value": "CGQQsZmd7rldGP////8PIP///////////wEojwcw5b/xvM7OBT0XAAAAQcsE+3EfAQAATYX///9RDtAxjMX0//9dAABEQWEAAAAAAIA3QGgBcg50ZXN0CXdpdGgJdGFic3oEAQIDBJIBAggjmgECCAqiAQIIFKgBAbABBbgBCdIBAgg2" } }, "signedSerialized": { "message": "CssHCjJ0eXBlLmdvb2dsZWFwaXMuY29tL3Byb3RvYnVmX3VuaXR0ZXN0LlRlc3RBbGxUeXBlcxKUBwhkELGZne65XRj/////DyD///////////8BKI8HMOW/8bzOzgU9FwAAAEHLBPtxHwEAAE2F////UQ7QMYzF9P//XQAAREFhAAAAAACAN0BoAXIOdGVzdAl3aXRoCXRhYnN6BAECAwSSAQIII5oBAggKogECCBSoAQGwAQW4AQnSAQIINvoBA2TIAYICDLGZne65XcuJ7I/3I4oCBgD/////D5ICCwD///////////8BmgIEjwf2AaICDuW/8bzOzgXkv/G8zs4FqgIIFwAAACoAAACyAhDLBPtxHwEAALFMx53rAgAAugIIhf///0EBAADCAhAO0DGMxfT//7HMkddMJwAAygIIAABEQcP1yEHSAhAAAAAAAIA3QGZmZmZmZkVA2gICAQDiAg50ZXN0CXdpdGgJdGFic+ICD0p1c3RBbm90aGVyVGVzdOoCBAECAwTqAgCCAwIII4IDAgg3igMCCAqKAwIIFJIDAggUkgMCCAqaAwIBAqIDAgUGqgMCCQeyAwIINrIDAggLugMECBYQZLoDBQghEMgBwgMOCLGZne65XRCxmZ3uuV3CAw4Iy4nsj/cjEMuJ7I/3I8oDBgj/////D8oDBhD/////D9IDCwj///////////8B0gMLEP///////////wHaAwYIjwcQjwfaAwYI9gEQ9gHiAxAI5b/xvM7OBRDlv/G8zs4F4gMQCOS/8bzOzgUQ5L/xvM7OBeoDCg0WAAAAFRcAAADqAwoNDAAAABUqAAAA8gMSCcsE+3EfAQAAEcsE+3EfAQAA8gMSCbFMx53rAgAAEbFMx53rAgAA+gMKDYX///8Vhf////oDCg1BAQAAFUEBAACCBBIJDtAxjMX0//8RDtAxjMX0//+CBBIJscyR10wnAAARscyR10wnAACKBAUVAABEQYoEBwgBFcP1yEGSBAkRAAAAAACAN0CSBAsIARFmZmZmZmZFQJoEAhABmgQCCAGiBB0KC0ZpcnN0U3RyaW5nEg50ZXN0CXdpdGgJdGFic6IEHwoMU2Vjb25kU3RyaW5nEg9KdXN0QW5vdGhlclRlc3SqBAYSBAQDAgGqBAIIAbIEBBICCCOyBAYIARICCDe6BAQSAggKugQGCAESAggUwgQEEgIIFMIEBggBEgIICsoEAhABygQECAEQAtIEAhAF0gQECAEQBtoEAhAJ2gQECAEQB+IEBBICCDbiBAYIARICCAs=", "signature": "AAECAwQ=", "publicKey": "AAECAwQ=", "publicKeySignature": "AAECAwQ=" } }
=================================================================
#1
First plain call: 524,4791 ms
Plain method call (avg): 514,3143 ms
First service call: 593,9198 ms
Avarage over 100: 514,6074 ms
#2
First plain call: 523,0690 ms
Plain method call (avg): 514,5455 ms
First service call: 586,1580 ms
Avarage over 100: 514,6934 ms
#3
First plain call: 508,8830 ms
Plain method call (avg): 514,5127 ms
First service call: 596,1040 ms
Avarage over 100: 514,6225 ms
#4 (plain using serialization-copy)
First plain call: 524,6345 ms
Plain method call (avg): 514,5882 ms
First service call: 549,5549 ms
Avarage over 100: 514,7216 ms
Test set: Sign configuration with Any TestAllTypes (no delay)
=================================================================
Input: { "componentName": "UnitTestComp", "serviceName": "UnitTestServ", "signed": { "message": { "@type": "type.googleapis.com/protobuf_unittest.TestAllTypes", "@value": "CGQQsZmd7rldGP////8PIP///////////wEojwcw5b/xvM7OBT0XAAAAQcsE+3EfAQAATYX///9RDtAxjMX0//9dAABEQWEAAAAAAIA3QGgBcg50ZXN0CXdpdGgJdGFic3oEAQIDBJIBAggjmgECCAqiAQIIFKgBAbABBbgBCdIBAgg2+gEDZMgBggIMsZmd7rldy4nsj/cjigIGAP////8PkgILAP///////////wGaAgSPB/YBogIO5b/xvM7OBeS/8bzOzgWqAggXAAAAKgAAALICEMsE+3EfAQAAsUzHnesCAAC6AgiF////QQEAAMICEA7QMYzF9P//scyR10wnAADKAggAAERBw/XIQdICEAAAAAAAgDdAZmZmZmZmRUDaAgIBAOICDnRlc3QJd2l0aAl0YWJz4gIPSnVzdEFub3RoZXJUZXN06gIEAQIDBOoCAIIDAggjggMCCDeKAwIICooDAggUkgMCCBSSAwIICpoDAgECogMCBQaqAwIJB7IDAgg2sgMCCAu6AwQIFhBkugMFCCEQyAHCAw4IsZmd7rldELGZne65XcIDDgjLieyP9yMQy4nsj/cjygMGCP////8PygMGEP////8P0gMLCP///////////wHSAwsQ////////////AdoDBgiPBxCPB9oDBgj2ARD2AeIDEAjlv/G8zs4FEOW/8bzOzgXiAxAI5L/xvM7OBRDkv/G8zs4F6gMKDRYAAAAVFwAAAOoDCg0MAAAAFSoAAADyAxIJywT7cR8BAAARywT7cR8BAADyAxIJsUzHnesCAAARsUzHnesCAAD6AwoNhf///xWF////+gMKDUEBAAAVQQEAAIIEEgkO0DGMxfT//xEO0DGMxfT//4IEEgmxzJHXTCcAABGxzJHXTCcAAIoEBRUAAERBigQHCAEVw/XIQZIECREAAAAAAIA3QJIECwgBEWZmZmZmZkVAmgQCEAGaBAIIAaIEHQoLRmlyc3RTdHJpbmcSDnRlc3QJd2l0aAl0YWJzogQfCgxTZWNvbmRTdHJpbmcSD0p1c3RBbm90aGVyVGVzdKoEBhIEBAMCAaoEAggBsgQEEgIII7IEBggBEgIIN7oEBBICCAq6BAYIARICCBTCBAQSAggUwgQGCAESAggKygQCEAHKBAQIARAC0gQCEAXSBAQIARAG2gQCEAnaBAQIARAH4gQEEgIINuIEBggBEgIICw==" } }, "unsigned": { "message": { "@type": "type.googleapis.com/protobuf_unittest.TestAllTypes", "@value": "CGQQsZmd7rldGP////8PIP///////////wEojwcw5b/xvM7OBT0XAAAAQcsE+3EfAQAATYX///9RDtAxjMX0//9dAABEQWEAAAAAAIA3QGgBcg50ZXN0CXdpdGgJdGFic3oEAQIDBJIBAggjmgECCAqiAQIIFKgBAbABBbgBCdIBAgg2" } } }
Output: { "componentName": "UnitTestComp", "serviceName": "UnitTestServ", "unsigned": { "message": { "@type": "type.googleapis.com/protobuf_unittest.TestAllTypes", "@value": "CGQQsZmd7rldGP////8PIP///////////wEojwcw5b/xvM7OBT0XAAAAQcsE+3EfAQAATYX///9RDtAxjMX0//9dAABEQWEAAAAAAIA3QGgBcg50ZXN0CXdpdGgJdGFic3oEAQIDBJIBAggjmgECCAqiAQIIFKgBAbABBbgBCdIBAgg2" } }, "signedSerialized": { "message": "CssHCjJ0eXBlLmdvb2dsZWFwaXMuY29tL3Byb3RvYnVmX3VuaXR0ZXN0LlRlc3RBbGxUeXBlcxKUBwhkELGZne65XRj/////DyD///////////8BKI8HMOW/8bzOzgU9FwAAAEHLBPtxHwEAAE2F////UQ7QMYzF9P//XQAAREFhAAAAAACAN0BoAXIOdGVzdAl3aXRoCXRhYnN6BAECAwSSAQIII5oBAggKogECCBSoAQGwAQW4AQnSAQIINvoBA2TIAYICDLGZne65XcuJ7I/3I4oCBgD/////D5ICCwD///////////8BmgIEjwf2AaICDuW/8bzOzgXkv/G8zs4FqgIIFwAAACoAAACyAhDLBPtxHwEAALFMx53rAgAAugIIhf///0EBAADCAhAO0DGMxfT//7HMkddMJwAAygIIAABEQcP1yEHSAhAAAAAAAIA3QGZmZmZmZkVA2gICAQDiAg50ZXN0CXdpdGgJdGFic+ICD0p1c3RBbm90aGVyVGVzdOoCBAECAwTqAgCCAwIII4IDAgg3igMCCAqKAwIIFJIDAggUkgMCCAqaAwIBAqIDAgUGqgMCCQeyAwIINrIDAggLugMECBYQZLoDBQghEMgBwgMOCLGZne65XRCxmZ3uuV3CAw4Iy4nsj/cjEMuJ7I/3I8oDBgj/////D8oDBhD/////D9IDCwj///////////8B0gMLEP///////////wHaAwYIjwcQjwfaAwYI9gEQ9gHiAxAI5b/xvM7OBRDlv/G8zs4F4gMQCOS/8bzOzgUQ5L/xvM7OBeoDCg0WAAAAFRcAAADqAwoNDAAAABUqAAAA8gMSCcsE+3EfAQAAEcsE+3EfAQAA8gMSCbFMx53rAgAAEbFMx53rAgAA+gMKDYX///8Vhf////oDCg1BAQAAFUEBAACCBBIJDtAxjMX0//8RDtAxjMX0//+CBBIJscyR10wnAAARscyR10wnAACKBAUVAABEQYoEBwgBFcP1yEGSBAkRAAAAAACAN0CSBAsIARFmZmZmZmZFQJoEAhABmgQCCAGiBB0KC0ZpcnN0U3RyaW5nEg50ZXN0CXdpdGgJdGFic6IEHwoMU2Vjb25kU3RyaW5nEg9KdXN0QW5vdGhlclRlc3SqBAYSBAQDAgGqBAIIAbIEBBICCCOyBAYIARICCDe6BAQSAggKugQGCAESAggUwgQEEgIIFMIEBggBEgIICsoEAhABygQECAEQAtIEAhAF0gQECAEQBtoEAhAJ2gQECAEQB+IEBBICCDbiBAYIARICCAs=", "signature": "AAECAwQ=", "publicKey": "AAECAwQ=", "publicKeySignature": "AAECAwQ=" } }
=============================================================
#1
First plain call: 1,5647 ms
Plain method call (avg): 0,0255 ms
First service call: 40,8435 ms
Avarage over 100: 0,4550 ms
#2
First plain call: 1,5115 ms
Plain method call (avg): 0,0257 ms
First service call: 44,6056 ms
Avarage over 100: 0,4919 ms
#3
First plain call: 1,6204 ms
Plain method call (avg): 0,0254 ms
First service call: 45,5780 ms
Avarage over 100: 0,4815 ms
#4 (plain using serialization-copy)
First plain call: 3,0675 ms
Plain method call (avg): 0,0315 ms
First service call: 41,1928 ms
Avarage over 80.000: 0,4382 ms
Looking over these results, I'm not sure anymore if adding the in-process handling is worth the additional effor.
I used a Intel Core i7-2640M @ 2.80 GHz for my tests.
ThanksMalc
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/a6b8fc30-d6d7-4002-81c6-6e15997442f2%40googlegroups.com.
On Fri, Oct 7, 2016 at 4:05 PM, Malc <marki...@gmail.com> wrote:I have a slightly different usecase in mind.We would like to move a legacy system to using gRPC. All new stuff can go there easy; but for the older components it would be useful to migrate first to an in-process separation of interface, and then to pull those out into external services as we get more mature in them.Being in the same memory space allows us to start building an interface while having some of the more malignant elements still worming their way through the global namespace; until we pick those out too.Is there a likely date in the future that this might be available?At this point, there's no ETA, and it's very unlikely this would happen before the end of 2016. On the other hand, for what you are describing, you don't really need an in-process server. You can run a server on localhost (on an autoselected port) and then connect to it with your clients. You can have as many servers and clients in the same process as you want. Memory space will be the same you cheating as you describe it will be possible.
ThanksMalc
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/a6b8fc30-d6d7-4002-81c6-6e15997442f2%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CACF4M0Qp0bk19iHzoBdtKqa%3D8APG_6HBinjGZUWGt_NRsEUNtA%40mail.gmail.com.
Do you have an idea, when this would happen? It it very important for us. I tried to do something by myself. Just getting a direct reference to the server class in the client. But all important classes are internal.
server = new Server { Services = { YourService.BindService(new YourServiceImpl()) }, Ports = { { "localhost", ServerPort.PickUnused, SslServerCredentials.Insecure } } }; server.Start(); channel = new Channel("localhost", server.Ports.Single().BoundPort, ChannelCredentials.Insecure);
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/46a12e0c-1005-4a37-8caa-12070c965b16%40googlegroups.com.