General Feedback

[desa]

• The tool is suitable only write queries. (Maybe development team will add also read part of it.)
• When we start test, while influx-stress is writing data to db, client (running test) cannot access to influxDb concurrently. And also, almost half of insert query get an error as "Error sending write: dialing to the given TCP address timed out". I think stress test try to use whole network and it leads to overload. (This is not a bug.)
• The documentation in github is really incomplete. I found some keys in code such as "username" is "user", "password" is "pass". I thought keywords would be the same with influxdb.
• When the test is finished, the total write data is prompt in console, if you compare the count with influxdb, they are not equal. (For example; stress test say 9.000.000 points is written, but when I query the db with count is almost 7 million.)

[desa]

• The tool is suitable only write queries. (Maybe development team will add also read part of it.)

Yup it' been on my todo list to add query support. I'll be sure to get on that.

• When we start test, while influx-stress is writing data to db, client (running test) cannot access to influxDb concurrently. And also, almost half of insert query get an error as "Error sending write: dialing to the given TCP address timed out". I think stress test try to use whole network and it leads to overload. (This is not a bug.)

This is most likely because you were putting too much HTTP load on the instance. I've observed similar behavior when pushing an instance to its limits.

• The documentation in github is really incomplete. I found some keys in code such as "username" is "user", "password" is "pass". I thought keywords would be the same with influxdb.

This was an oversight. I'll get it fixed immediately.

• When the test is finished, the total write data is prompt in console, if you compare the count with influxdb, they are not equal. (For example; stress test say 9.000.000 points is written, but when I query the db with count is almost 7 million.)

I just noticed that this issue exists even if there are no failed writes. If there were failed writes, this is partially by design, but can be changed. At the moment, we don't retry failed writes, I'll add a flag that retries until success.

@bahadirbal any other feedback?

[bahadirbal]

Thank you Desa for your action,

Yup it' been on my todo list to add query support. I'll be sure to get on that.

Previous version of Influx_stress, I reliazed that write & query works one at a time. Maybe, I am wrong. I think that there should be option to work also concurrently.

At the moment, we don't retry failed writes, I'll add a flag that retries until success.

I think this is good insight for stress test, If there were failed writes, you can tell to tester X failed and Y success writes. In my opinion, retry until success approach makes looping sometimes.

Again thank you, I will continue follow this project and If any feedback, I will share with you.

[desa]

@bahadirbal

Previous version of Influx_stress, I reliazed that write & query works one at a time. Maybe, I am wrong. I think that there should be option to work also concurrently.

You're entirely correct influx_stress supported concurrent reads and writes. The big issue with it was that the queries generated were usually naive and hard to configure. I was planning on adding a query subcommand influx-stress, but I definitely agree that there should also be a option to run it concurrently from the insert subcommand.

I think this is good insight for stress test, If there were failed writes, you can tell to tester X failed and Y success writes. In my opinion, retry until success approach makes looping sometimes.

We currently track this data internally, but you're entirely right, I should report this to the user. I also discovered an issue where its possible to overwrite data. I'll open a separate issue for that today.

[desa]

I just noticed that this issue exists even if there are no failed writes. If there were failed writes, this is partially by design, but can be changed. At the moment, we don't retry failed writes, I'll add a flag that retries until success.

This issue is fixed

[desa]

Closing issue in favor of separate issues