Moved from GitHub dgraph-js/18
Posted by jeffkhull:
---------------------------------------------------------
Versions:
Dgraph v1.02
dgraph-js v1.03
Windows 10 client
Ubuntu / Virtualbox Dgraph server / zero / ratel
Using this query as an example:
{ adminUsers(func: eq(VertexType, "User")) @filter(eq(IsAdministrator, "1")) { uid } }
Actual console .time() / timeEnd() in node shows 1186 ms. However, while running in debug mode, the latency reported by the server tells a different story:
“latency”:{“parsingNs”:11466,“processingNs”:467761,“encodingNs”:1090106}}
So the latency of the query on the dgraph server should be 0.011 ms + 0.467 ms + 10.9 ms = ~11ms, but latency in the code using the client is ~100x higher. When using Dgraph ratel, I see very low latency, so this problem seems to be within the JS client.
Any initial thoughts on what might be causing this? In the meantime, I’ll put some more timers within the module to pinpoint where the high latency may be coming from and comment back here.
UPDATE:
I have some detailed times from the functions inside the library. I don’t understand GRPC very well, but I put one time output in the request serialize function, and one time output in the response constructor function. Total query latency experienced by my app was 1032 ms, and 1009 ms of these were between the request serialize / response constructor calls. So can I conclude that this is a network latency problem for grpc on my machine?
Original query:
{
adminUsers(func: eq(VertexType, “User”)) @filter(eq(IsAdministrator, “1”)) {
uid
}
}
Debug messages (times added)
{“query”:"{\n adminUsers(func: eq(VertexType, “User”)) @filter(eq(IsAdministrator, “1”)) {\n uid\n }\n }",“varsMap”:,“startTs”:0,“linRead”:{“idsMap”:}}
Returning from proto.api.Request.prototype.serializeBinary: 41085725 (time in ms)
in constructor proto.api.Response: 41086734 (time in ms)
(1009 MS between request serialize and response constructor)
proto.api.Response.toObject: 0.435ms
Query response:
{“json”:“eyJhZG1pblVzZXJzIjpbeyJ1aWQiOiIweDNhYTE5In0seyJ1aWQiOiIweDk0Zjc4In1dfQ==”,“schemaList”:,“txn”:{“startTs”:11351,“commitTs”:0,“aborted”:false,“keysList”:,“linRead”:{“idsMap”:[[1,1013]]}},“latency”:{“parsingNs”:14972,“processingNs”:334063,“encodingNs”:1605714}}
Total query latency in my app code: 1032.438ms
UPDATE 2:
I have found that by running the application within the VirtualBox Ubuntu installation rather than accessing from Windows, the grpc latency problem goes away completely, so I’m going to consider this a grpc latency problem rather than a problem with the library. Closing the issue.