Codecov Report

Attention: Patch coverage is 96.05263% with 3 lines in your changes missing coverage. Please review.

Project coverage is 65.44%. Comparing base (f8a629b) to head (f53032e).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main     #142      +/-   ##
==========================================
+ Coverage   63.43%   65.44%   +2.00%     
==========================================
  Files          34       35       +1     
  Lines        2210     2266      +56     
==========================================
+ Hits         1402     1483      +81     
+ Misses        808      783      -25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Is it possibly to get a syntax example on how we need to configure the no_sync within our Python code?

I am trying the following and getting some errors:

Maybe this hasn't been added to a new release yet? The Repo and my installed version is reporting 0.13.0. which looks like it was released 3 weeks ago and this was just approved last week.

Maybe this hasn't been added to a new release yet? The Repo and my installed version is reporting 0.13.0. which looks like it was released 3 weeks ago and this was just approved last week.

@dburton-influxdata , you can always check the CHANGELOG.md to see what features comes into which release. This change goes into the upcoming 0.14.0 version which was not released yet. Do you need this feature? Should we speed up the release process?

@jansimonb yes, I am doing some v1 to V3 data migration development and testing. I believe I was able to patch my installed version with your fix last night. However our test run using the no_sync=True didn't show any time savings. I am wanting to test with the gzip feature possibly today as well.

Did you test the no_sync=True option to verify any write performance gains with V3?

Did you test the no_sync=True option to verify any write performance gains with V3?

Yes, I tested it against a local docker-installed influxdb3 server. It is much faster with no_sync=true:

With no_sync=false:

write 0 in 0.5645s
write 1 in 1.0031s
write 2 in 0.9984s
write 3 in 1.0062s
write 4 in 0.9919s

With no_sync=true:

write 0 in 0.0061s
write 1 in 0.0012s
write 2 in 0.0007s
write 3 in 0.0009s
write 4 in 0.0007s

One option is to set the no_sync flag is via constructor:

    with InfluxDBClient3(token=token, host=host, database=db,
                         write_client_options=write_client_options(
                             write_options=WriteOptions(
                                 write_type=WriteType.synchronous,
                                 write_precision=WritePrecision.US,
                                 no_sync=True
                             )
                         )) as _client:

or you can also set it via env:

    os.environ["INFLUX_HOST"] = host
    os.environ["INFLUX_TOKEN"] = token
    os.environ["INFLUX_DATABASE"] = db
    os.environ["INFLUX_WRITE_NO_SYNC"] = "true"

    with InfluxDBClient3.from_env() as _client:

But please note that this change is still not released yet.

Jan, Thank you for your response and the examples. I believe I go tit to work for our initial testing and I look forward to the updated release.

Question: How big was the data set that you used for testing?

Question: How big was the data set that you used for testing?

I tested just with writing a single record. For a single record the saved time approximately equals to the wal-flush-interval set on server. For larger dataset this can be different based the overall WAL configuration.

@dburton-influxdata , fyi, the feature was released.

@jansimonb Did this release include the should_gzip feature also get released?

Either way, do you know or can you find out if we can gzip the query response (payload)?