-
Notifications
You must be signed in to change notification settings - Fork 28.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SPARK-26363][WebUI] Avoid duplicated KV store lookups in method taskList
#23310
Conversation
executorLogs
in TaskData
Test build #100095 has started for PR 23310 at commit |
Agree -- CC @pgandhi999 |
retest this please. |
Test build #100120 has finished for PR 23310 at commit
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Btw, given that there's change on response on public API, might this PR need to be treated as backward incompatible change?
@HeartSaVioR #21688 is only on master. IMO we don't need to consider backward incompatibility. |
@gengliangwang Ah my bad. Thanks for noticing. LGTM. |
overall makes sense, the only downside is less on server side, but can always be added back later. Were you seeing specific performance issue or slow load time with this? |
@tgravescs I found the issue when I merge the code changes to our product. I don't try it in large application to get performance difference. Performance is not the key motivation. We can use a hash map to reduce the number of KV store lookups. The main point of this PR is about the data structure |
I'm not against the change, one can argue both ways whether it should be in the scope of task data or not. I personally don't see that as a problem based on how we are trying to do server side stuff here. In many ways it makes sense for the rest api to return exactly what you want for your UI so you don't have to do joins or lookups on other tables. logs are directly related to tasks so from a logical perspective they do belong there. Actually I hate how when we stop tracking executors to save memory the log links go away. Its very annoying from a debugging point of view. Reducing the # of lookups should be good. I was just wanting to know if you actually saw a performance issue with this or not. I can change any code I want because I think its better but unless I measure it to prove that it doesn't mean it does or is necessary. In this case since we don't do the executor table on the server side I think this is ok, theoretically that could get out of sync with the task table since its doing server side lookups and not reloading the entire page. This change could make that slightly worse if you get new executors not in that table. But until/if we convert everything to server side I think that is ok. |
@tgravescs Thanks for the explanation. Totally agree. |
Retest this please. |
@@ -348,9 +348,9 @@ $(document).ready(function () { | |||
|
|||
// prepare data for executor summary table | |||
stageExecutorSummaryInfoKeys = Object.keys(responseBody.executorSummary); | |||
var executorDetailsMap = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gengliangwang . Is this filled correctly always? I'm hitting the following error during reviewing this patch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is caused by the cache of browser. The javascript might be using the cached one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try loading the page without cache should work: https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gengliangwang you're sure it works locally? I just want to make sure as I'm not sure how well tests cover this case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@srowen I tested locally with the event logs under core/src/test/resources/spark-events
, manually compare the log URL of stage pages in application_1538416563558_0014
. Also check if any error/warning in chrome console.
Everything works well.
Test build #100213 has finished for PR 23310 at commit
|
{data : "executorLogs", name: "Logs", render: formatLogsCells}, | ||
{ | ||
data : function (row, type) { | ||
if(executorDetailsMap[row.executorId] && executorDetailsMap[row.executorId]["executorLogs"]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing space after if
$.getJSON(createRESTEndPointForExecutorsPage(appId), | ||
function(executorSummaryResponse, status, jqXHR) { | ||
var executorDetailsMap = {}; | ||
executorSummaryResponse.forEach(function (executorDetail) { | ||
executorDetailsMap[executorDetail.id] = executorDetail; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So one issue I think here is that this is being filled in async from what the task table is being filled in and referencing this field. You could potentially have issues where this hasn't finished by the time the task table wants to use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh sorry about that.
Then I think we should just use a hash map in the backend.
This reverts commit 1cfd872c9f64b214ef4a3a17b507033bf296d60b.
1cfd872
to
67992a5
Compare
Test build #100339 has finished for PR 23310 at commit
|
Test build #100338 has finished for PR 23310 at commit
|
It looks like the change now doesn't match the title and description. Does this actually address the original issue? |
At a high level it could be better because he is storing the executor info in executorIdToLogs hashmap as he goes through each executor and if you have multiple tasks on the same executor it would have already loaded that info from the kv store. So it could be less lookups. Need to look in more detail. |
LGTM. I see that this will reduce the loading time of the page significantly especially when there are multiple tasks running on same executor. |
@srowen The new changes use a hash map to reduce the duplicated KV store lookups inside one method call
What do you think? |
@gengliangwang OK this is a narrower change than it was originally. That's fine if it's an improvement. I'd just suggest you modify the JIRA and/or PR description to reflect the current change as needed. |
taskList
Test build #4488 has finished for PR 23310 at commit
|
Merged to master |
@srowen @tgravescs @pgandhi999 Thanks for the review. And again, sorry for the mistake. |
…kList` ## What changes were proposed in this pull request? In the method `taskList`(since apache#21688), the executor log value is queried in KV store for every task(method `constructTaskData`). This PR propose to use a hashmap for reducing duplicated KV store lookups in the method. ![image](https://user-images.githubusercontent.com/1097932/49946230-841c7680-ff29-11e8-8b83-d8f7553bfe5e.png) ## How was this patch tested? Manual check Closes apache#23310 from gengliangwang/removeExecutorLog. Authored-by: Gengliang Wang <gengliang.wang@databricks.com> Signed-off-by: Sean Owen <sean.owen@databricks.com>
What changes were proposed in this pull request?
In the method
taskList
(since #21688), the executor log value is queried in KV store for every task(methodconstructTaskData
).This PR propose to use a hashmap for reducing duplicated KV store lookups in the method.
How was this patch tested?
Manual check