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

Parallelize YAML processing for pods in APIserver. #4598

Closed
wants to merge 1 commit into from

Conversation

gmarek
Copy link
Contributor

@gmarek gmarek commented Feb 19, 2015

I'm not sure how useful is this change. In single threaded environment it's bad, as it's impossible to fail fast. In multithreaded it helps a bit.

@googlebot
Copy link

Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.

@erictune
Copy link
Member

We should probably hold off on adding parallelizing optimizations to the APIserver until we have consistently run the existing apiserver code with multiple threads. AFAICS, we don't set GOMAXPROCS for apiserver.

@gmarek
Copy link
Contributor Author

gmarek commented Feb 20, 2015

As per #4521 we're setting GOMAXPROCS now. But I agree that we should hold this change until we know how APIserver works in multithreaded environment.

@erictune
Copy link
Member

erictune commented Mar 4, 2015

gmarek what is the status on this?

@erictune
Copy link
Member

erictune commented Mar 4, 2015

@gmarek

@gmarek
Copy link
Contributor Author

gmarek commented Mar 5, 2015

That I don't know. I wrote this in hope that it'll speed up APIserver, but gains are not very big. The side effect that I didn't fix in this PR is that ordering of the output is not deterministic anymore. There'll need to be some kind of sorting somewhere later in the code path. I'll do it, if you think this PR makes sense, as a part or general parallelization of Kubernetes. If not, we can just drop it.

@erictune
Copy link
Member

erictune commented Mar 5, 2015

I don't think this makes sense at this time if the wins are not big.

@erictune erictune closed this Mar 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants