Skip to content
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

(WIP) task search efficiency #932

Merged
merged 16 commits into from Mar 4, 2016
Merged

(WIP) task search efficiency #932

merged 16 commits into from Mar 4, 2016

Conversation

@ssalinas
Copy link
Member

ssalinas commented Mar 2, 2016

Working on a few improvements:

  • Speed up getInactiveTaskIds by finding them directly instead of finding active tasks then removing from an array of all tasks. We make the same number of zk calls either way, might as well have the results we want from them.
  • batch together calls for getting SingularityTaskHistoryUpdates
  • Store SingularityTaskIdHistorys in the zk history path so we can access them more easily
    /cc @tpetr @Calvinp
@ssalinas ssalinas changed the title (WIP) task search efficiency (WIP) task search efficiency Mar 2, 2016
@ssalinas ssalinas force-pushed the task_search_speed branch from 9f9e970 to 267fc12 Mar 2, 2016
public void processResult(CuratorFramework client, CuratorEvent event) throws Exception {
if (event.getStat() == null) {
objects.add(pathsMap.get(event.getPath()));
latch.countDown();

This comment has been minimized.

Copy link
@wsorenson

wsorenson Mar 3, 2016

Contributor

what's the point of these 2 statements? latch.countDown(); return; --> latch.countDown()

This comment has been minimized.

Copy link
@ssalinas

ssalinas Mar 3, 2016

Author Member

ah, yeah that could just be outside the if and without the return, will fix

This comment has been minimized.

Copy link
@jhaber

jhaber Mar 3, 2016

Member

I may be paranoid but I usually do try { x; } finally { latch.countDown(); } just in case an exception is thrown the latch still gets decremented

This comment has been minimized.

Copy link
@wsorenson

wsorenson Mar 3, 2016

Contributor

good point

@ssalinas
Copy link
Member Author

ssalinas commented Mar 3, 2016

@wsorenson - Consolidated some of the methods in CuratorAsync so we aren't repeating as much
@jhaber - put all the latch count downs in finally blocks as well

@@ -241,5 +282,60 @@ public void processResult(CuratorFramework client, CuratorEvent event) throws Ex
}
}

}
protected <T, Q> Map<T, List<Q>> getAsyncAsMapThrows(final String pathNameForLogs, final Map<String, T> parentPathsMap, final String subpath, final Transcoder<Q> transcoder) throws Exception {

This comment has been minimized.

Copy link
@tpetr

tpetr Mar 3, 2016

Member

method name seems kinda vauge

@ssalinas
Copy link
Member Author

ssalinas commented Mar 3, 2016

Summary of changes:

  • implement notExists in curator async to get inactive task ids without having to get active task ids then filter
  • batch together any calls for task history updates using new getAsyncAsMap in curator async
  • begin storing current SingularityTaskIdHistory for a task in the /tasks/history/(requestId)/(taskId) node, and write a migration to backfill. This will update on each status update for the task
String updatePath = getUpdatePath(taskHistoryUpdate.getTaskId(), taskHistoryUpdate.getTaskState());
String updatesPath = getUpdatesPath(taskHistoryUpdate.getTaskId());
String historyPath = getHistoryPath(taskHistoryUpdate.getTaskId());
String reqeustPath = getRequestPath(taskHistoryUpdate.getTaskId().getRequestId());

This comment has been minimized.

Copy link
@tpetr

tpetr Mar 3, 2016

Member

typo

@ssalinas ssalinas added the hs_staging label Mar 3, 2016
@ssalinas
Copy link
Member Author

ssalinas commented Mar 4, 2016

@wsorenson had to undo some of the consolidation of those async methods, turns out having the callbacks com from other methods, I was getting ConcurrentModification and related exceptions when trying to run things.

Also, implemented what I talked about with @tpetr and started storing the json of the SingularityTaskIdHistory object in the /tasks/history/(requestId)/(taskId) node. The benefit of this ebing that we can now just use one getAsync call to gather up many id histories instead of having to build each from multiple calls. At the moment, it will update this json on each status update so that the task is history has the most recent task state. Thoughts on that strategy?

@wsorenson
Copy link
Contributor

wsorenson commented Mar 4, 2016

I'm not sure it's worth all that effort to duplicate data and re-save data on updates just to make admin task search more efficient.

@ssalinas
Copy link
Member Author

ssalinas commented Mar 4, 2016

@wsorenson did some refactoring, zk migration is taken out, and methods in curator async each build their own callback then call a shared method to actually execute the query, watch the latch, and return results

@ssalinas ssalinas added the hs_qa label Mar 4, 2016
ssalinas added a commit that referenced this pull request Mar 4, 2016
(WIP) task search efficiency
@ssalinas ssalinas merged commit 8ba0273 into task_search Mar 4, 2016
0 of 2 checks passed
0 of 2 checks passed
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details
@ssalinas ssalinas deleted the task_search_speed branch Mar 4, 2016
@ssalinas ssalinas modified the milestone: 0.4.12 Apr 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.