nickva commented on code in PR #5448: URL: https://github.com/apache/couchdb/pull/5448#discussion_r1982708254
########## src/docs/src/whatsnew/3.5.rst: ########## @@ -0,0 +1,172 @@ +.. Licensed under the Apache License, Version 2.0 (the "License"); you may not +.. use this file except in compliance with the License. You may obtain a copy of +.. the License at +.. +.. http://www.apache.org/licenses/LICENSE-2.0 +.. +.. Unless required by applicable law or agreed to in writing, software +.. distributed under the License is distributed on an "AS IS" BASIS, WITHOUT +.. WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the +.. License for the specific language governing permissions and limitations under +.. the License. + +.. _release/3.5.x: + +============ +3.5.x Branch +============ + +.. contents:: + :depth: 1 + :local: + +.. _release/3.5.0: + +Version 3.5.0 +============= + +Highlights +---------- + +* :ghissue:`5399`, :ghissue:`5441`, :ghissue:`5443`: Implement parallel + ``pread`` calls: lets clients issue concurrent ``pread`` calls without blocking + each other or having to wait for all writes and ``fsync`` calls. This is + enabled by default and can be disabled with ``[couchdb] use_cfile = false`` in + the configuration. + + CouchDB already employs a multiple-parallel-read and concurrent serial-write + design at the database engine layer, but below that in the storage engine, + each file representing a database shard is required to route all read / write + / sync requests through a single Erlang process that owns the file descriptor + (fd). + + An Erlang process can at most execute at the speed of a single CPU core. Two + scenarios can lead to a starvation of the fd-owning Erlang process message + inbox: + + - 1000s concurrent read requests with a constant stream of writes per shard, + or: + - a high latency storage devices like network block storage. + + Parallel preads re-implements the Erlang ``file`` module in parts as + ``couch_cfile`` to allow multiple ``dup()``’d file descriptors to be used for + reading and writing. Writes continue to be serialised at the database engine + layer, but reads now are no longer blocked by writes waiting to commit. + + Comes with an extensive test suite that includes property testing to ensure + ``couch_cfile`` behaves exactly like Erlang’s ``file`` in all other cases. + + Performance is always equal or better than before. These scenarios show + preliminary improvements: + + - random document reads: 15% more throughput + - read ``_all_docs``: 15% more throughput + - read ``_all_docs`` with ``include_docs=true``: 25% more throughput + - read ``_changes``: 4% more throughput + - single document writes: 8% more throughput + - 2000x concurrent clients, random document reads on a 12 node cluster: 30% more + throughput + - concurrent constant document writes and concurrent single document reads on + a single shard: 40% more throughput. + + This feature is not available on Windows. + +* :ghissue:`5435`: Improve default ``chttpd_server`` options. This helps with + faster processing of many concurrent TCP connections. + +* :ghissue:`5347`: Fix attachment size calculation. This could lead to shards + not being scheduled for compaction correctly. + +Performance +----------- + +* :ghissue:`5417`: Fix ``atts_since`` functionality for document ``GET`` + requests. + Avoids re-replicating attachment bodies on doc updates. +* :ghissue:`5389`: Save 1 ``write`` for each committing data to disk by using + ``fdatasync`` while keeping the same level of storage reliability. + +Features +-------- + +* :ghissue:`5429`: Nouveau: upgrade ``dropwizard`` to 4.0.12. Review Comment: 5429 doesn't match, should be 5439? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
