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

Make it possible to run two Renaissance instances side by side #13

Open
lbulej opened this issue Apr 9, 2019 · 4 comments
Open

Make it possible to run two Renaissance instances side by side #13

lbulej opened this issue Apr 9, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@lbulej
Copy link
Member

lbulej commented Apr 9, 2019

I'm not sure whether it is possible or not at the moment, but as we merge benchmarks with complex underlying frameworks, we should make sure that they can't step on each other's toes.

This is probably easy for things such as scratch space -- the harness should provide a benchmark with a scratch directory beneath a global scratch space.

It's probably going to be more difficult for things such as port numbers, if we use benchmarks that communicate over socket (Spark comes to mind).

@axel22
Copy link
Member

axel22 commented Apr 9, 2019

That's a good point - we should probably create a scratch subdirectory when running a benchmark, and ensure that it runs within it.

Not sure how the address issues such as ports, other than being knowledgeable about this when writing the benchmark, and having the harness assign it through the configuration object.

@davleopo
Copy link
Collaborator

BTW in #17 I added logic to have common scratch dir generation for spark benchmarks, maybe we should adhere to this for the entire suite.

@axel22
Copy link
Member

axel22 commented Apr 17, 2019

Regarding ports, note that many of the frameworks have some configurability options regarding the ports that they use.

@farquet farquet added the enhancement New feature or request label May 8, 2019
@farquet farquet added this to the 1.0.0 milestone May 8, 2019
@farquet farquet removed this from the 1.0.0 milestone Dec 2, 2020
@farquet
Copy link
Collaborator

farquet commented Dec 2, 2020

Based on the non trivial aspect of the issue and the fact that there exists tools to trap processes in their own environment (firejail or even docker), I'm removing the 1.0.0 milestone for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants