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

establish more connections in cassandra-stress #53

Open
glommer opened this issue Nov 22, 2017 · 8 comments
Open

establish more connections in cassandra-stress #53

glommer opened this issue Nov 22, 2017 · 8 comments

Comments

@glommer
Copy link
Contributor

glommer commented Nov 22, 2017

In many occasions we are forced to run multiple clients not because there is a bottleneck in the client machine, but because the low number of connections.

Ideally, we would make the number of connections configurable, and then tune that. A change like this should find its way to the upstream cassandra-stress project.

Bonus point if we can have a wrapper script that somehow connects to the Scylla REST or other jmx metrics, finds out what is the number of shards, and opens as many connections as there are shards.

@avikivity
Copy link
Member

REST isn't a good idea, because you need to set up another connection with its own configurable port number, authentication, and encryption.

Better read a new column from system.local or a new virtual table. This could then be done in the driver and apply to all applications, not just cassandra-stress.

@glommer
Copy link
Contributor Author

glommer commented Nov 22, 2017

I am totally fine with that.

@glommer
Copy link
Contributor Author

glommer commented Mar 17, 2018

As of a0076e7, cassandra-stress upstream supports setting the number of connections.

Since we also want a newer version to fix coordinated omission, I strongly suggest we upgrade.

@eyalgutkind
Copy link

Did we resolve this one?

@avikivity
Copy link
Member

This should be resolved by bundling the shard-aware driver instead of the datastax driver.

@haaawk what's the best way to do that? IMO we should do a formal release of the shard-aware driver (i.e. with a tag, version number, and upload to the binary repo) and bundle that.

@haaawk
Copy link
Contributor

haaawk commented Feb 18, 2019

@avikivity I agree that publishing our driver as maven artifact is the best way to do it. In the mean time we can just put our driver into tools instalation.

@avikivity
Copy link
Member

What does "put our driver into tools installation" mean? Copy it to libs/? I don't want to use a non-released version (although, it's not really that terrible if it's a hidden component).

btw we're also facing a similar problem with the Python driver that is bundled in scylla-tools-java.git.

@haaawk
Copy link
Contributor

haaawk commented Feb 18, 2019

I would have to double check but putting the jar in libs should work. We might need to change some build scripts too but I'm not 100% sure without giving it a try.

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

No branches or pull requests

4 participants