Measure performance of TSPClient before and after JSON-RPC #999
Conversation
There was a problem hiding this comment.
Thanks @hoangphamEclipse for this effort; well appreciated. I'd have these comments, some minor edit ones and the others more "fundamental". There could be more work ahead given these potentially opening aspects.
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
| 3. For fetchTimeGraphStates(), the JSON-RCP update takes more time compared to the HTTP direct implementation. | ||
|
|
||
| One of the possible explanation is the difference in the amount of data that needs to be sent to the back end. This is true for the case of the `fetchXYTree()` and the `fetchTimeGraphStates()` tests. Since they both serialize a good amount of data, the performance either stays the same - in the case of `fetchXYTree()` where we have small amount of data - or becomes worse - in the case of `fetchTimeGraphStates()` where we have a decent amount of data. | ||
|
|
There was a problem hiding this comment.
A missing test case might be, to measure the impact on a trailing yet tiny payload request, preceded by a heavy one. Meaning, is the trailing (tiny) request starved in any way by the preceding elephant. We could compare the outcome of this test before versus after json-rpc. This was recently proposed by @MatthewKhouzam IIRC.
So I think he mentioned the tiny request being a trace annotations/markers one or so. -Preceded by some truckload data fetch act. The latter shouldn't starve or prevent the former from showing, IIUC. If this is an issue before changing to json-rpc, then measuring with the latter in turn might become irrelevant. The question could otherwise be, is the json-rpc wrapper (towards the back-ended client use) adding latency to the trailing/tiny request?
There was a problem hiding this comment.
@MatthewKhouzam since you are back, do you think this is a required test case?
hoangphamEclipse
force-pushed
the
json-rcp
branch
from
5d2b6fc
to
f979cc5
Compare
hoangphamEclipse
force-pushed
the
json-rcp
branch
7 times, most recently
from
c7e12ce
to
b0e92f8
Compare
hoangphamEclipse
changed the title
There was a problem hiding this comment.
Leaving this review up to @MatthewKhouzam and others if need be, given my recent focus change; thanks.
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
doc/performance/0002-http-vs-rcp-client-performance-analysis.md
Outdated
Show resolved
Hide resolved
bhufmann
requested review from
bhufmann and
marco-miller
and removed request for
marco-miller
This commit adds a study on the impact of the JSON-RPC patch on the Theia Front End - Back End - Trace Server communication speed. Relates to eclipse-cdt-cloud#990. Signed-off-by: Hoang Thuan Pham <[email protected]>
hoangphamEclipse
force-pushed
the
json-rcp
branch
from
b0e92f8
to
27b1429
Compare
There was a problem hiding this comment.
Looks good to me. Thanks!
@MatthewKhouzam could you please do another round of review since you gave comments initially?
This commit adds a study on the impact of the JSON-RPC patch on the Theia Front End - Back End - Trace Server communication speed.
Relates to #990.