This is an automated email from the ASF dual-hosted git repository.
wangdan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-pegasus-website.git
The following commit(s) were added to refs/heads/master by this push:
new ae6c63c7 Update backup requests docs (#89)
ae6c63c7 is described below
commit ae6c63c7a9f403236bf152647b0c20dbc225aad7
Author: Yingchun Lai <[email protected]>
AuthorDate: Mon Jan 27 11:17:34 2025 +0800
Update backup requests docs (#89)
---
_docs/en/administration/backup-request.md | 29 +++++++++++++++--------------
_docs/zh/administration/backup-request.md | 27 +++++++++++++--------------
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/_docs/en/administration/backup-request.md
b/_docs/en/administration/backup-request.md
index 657f4250..362a66b5 100644
--- a/_docs/en/administration/backup-request.md
+++ b/_docs/en/administration/backup-request.md
@@ -3,30 +3,31 @@ permalink: administration/backup-request
---
# Background
-In the current implementation of Pegasus, reading from secondary replicas can
lead to inconsistencies, so only primary replicas are used for reads. However,
in certain scenarios, such as load balancing or hotspot writes can cause
instability on the primary replica. To address this, we aim to enable reads
from secondary replicas when the primary is unstable. While this approach
sacrifices some strong consistency, it helps to alleviate long-tail latency in
read requests and improves overal [...]
+In the current implementation of Pegasus, reading from secondary replicas can
cause inconsistencies, so Pegasus defaults reading from primary replicas.
However, in certain situations (such as load balancing, hotspot writes, etc.),
the primary can often become unstable. Therefore, we hope to read from the
secondary when the primary is unstable, sacrificing some strong consistency to
reduce the tail latency of read requests and improve system availability.
Backup request is designed to ach [...]
# Design and Implementation
-Implementing of backup requests is relatively straightforward. For read
operations (write operations currently do not support backup requests), when a
client sends a request to the primary, it will wait for a specified delay
period (typically p999). If no response is received within this time, the
client will randomly select a secondary replica and send a backup request. The
first response received will be used.
-We recommend using p999 as the delay for sending secondary requests, as the
purpose of the backup request operation is to eliminate long-tail latency
rather than to improve cluster performance. Setting this value too low can
result in an overwhelming number of backup requests, thereby significantly
increasing the overall system load. For example, if the delay is set to p50,
50% of the requests would be sent to secondary replicas, causing a 50% increase
in system load.
+The implementation principle of the backup request is relatively simple: For
read operations (currently, write operations do not support backup requests),
when the client sends a request to the primary, if the response has not been
returned after a certain delay (usually p999), a secondary is randomly selected
and a backup request is sent to it. Finally, the fastest returned response is
processed.
-# How to Use
-In Pegasus Java Client v2.0.0, we introduced an interface that allows users to
enable the backup request feature for a specific table. The method is defined
as follows:
+We recommend choosing p999 as the delay time for sending secondary requests
because the backup request operation is intended to eliminate tail latency, not
to improve cluster performance. If the value is set too low, the large number
of backup requests will increase the cluster pressure (assuming p50 is chosen
as the delay, then 50% of the requests will send requests to the secondary, and
the system load will increase by 50%).
+# How to Use
+In Pegasus Java client v2.0.0, we have added an interface through which the
backup request function of a specific table can be enabled. The implementation
is as follows:
```java
public PegasusTableInterface openTable(String tableName, int
backupRequestDelayMs) throws PException;
```
-Compared to the previous version of the `openTable` interface, we’ve added the
`backupRequestDelayMs` parameter. This parameter defines the delay time in
milliseconds: if a request sent to the primary replica does not receive a
response within `backupRequestDelayMs`, a backup request will be sent to a
secondary replica. Notice that setting `backupRequestDelayMs <= 0` disables the
backup request feature.
+Compared to the old version of the `openTable` interface, we have added a
`backupRequestDelayMs` parameter. This parameter is the delay mentioned above,
i.e.: sending a request to the primary, if the response has not returned after
`backupRequestDelayMs` milliseconds, then send a backup request to the
secondary. Note that `backupRequestDelayMs <= 0` means disabling the backup
request feature.
+
+In addition, in the old version of the `openTable` interface, the backup
request feature is disabled by default.
-In previous versions of the openTable interface, the backup request mechanism
was disabled by default.
+# Benchmark
-# Performance Testing
-The table below compares the performance between enabling and disabling backup
requests. We used the p999 latency of read without backup requests (138 ms) as
the delay for triggering backup requests. The data shows that enabling backup
requests has **no significant impact** on the p999 latency for `get` requests,
but the p9999 latency is **reduced by several times**.
+The following table shows the performance comparison of whether the backup
request is enabled. Here we selected the p999 time of read requests when the
backup request is not enabled as the delay time for the backup request (138ms).
The data shows that after enabling the backup request, the p999 latency of get
requests **remains almost unchanged**, while the p9999 latency is **reduced by
several times**.
-Additionally, since the delay is set to the p999 value, approximately one out
of every thousand requests triggers a backup request. This results in an
additional request load (i.e., the overhead of enabling backup requests) of
approximately 0.1%. Similarly, setting the `backupRequestDelayMs` to p99 can
further reduce the p999 latency, which may increase the additional read request
load by around 1%.
+In addition, since the delay time is set to p999 time, about 1 out of 1000
requests will send a backup request, so the proportion of additional request
volume (i.e., the additional overhead of enabling the backup request) is about
0.1%. By analogy, if you want to reduce P999 latency, you can set
`backupRequestDelayMs` to P99 latency, which will increase the additional read
traffic by 1%.
-| Test Case | Backup Request Enabled | Read p9999 |
-|-------------------------|------------------------|------------|
-| 3 Clients, 15 Threads | No | 988,671 |
-| 3 Clients, 15 Threads | Yes | 153,599 |
+| test case | enable backup request | read p9999 latency in
microsecond |
+|----------------------|-----------------------|-----------------------------------|
+| 3-clients 15-threads | no | 988,671
|
+| 3-clients 15-threads | yes | 153,599
|
diff --git a/_docs/zh/administration/backup-request.md
b/_docs/zh/administration/backup-request.md
index ea5bc324..4c39ec7a 100644
--- a/_docs/zh/administration/backup-request.md
+++ b/_docs/zh/administration/backup-request.md
@@ -3,32 +3,31 @@ permalink: administration/backup-request
---
# 背景
-在当前的Pegasus实现中，由于向secondary读取会导致不一致的情况发生，所以目前Pegasus仅仅支持对primary副本的读取。但是在某些情况下（例如：负载均衡、热点写入等）经常会导致primary不稳定。所以我们希望在primary不稳定时能够读取secondary，通过牺牲部分强一致性来降低读请求的长尾并提高系统的可用性。backup
request便是用来实现此功能的。
+在当前的 Pegasus 实现中，由于向 secondary 读取会导致不一致的情况发生，所以 Pegasus 默认只对 primary
副本的读取。但是在某些情况下（例如：负载均衡、热点写入等）经常会导致 primary 不稳定。因此，我们希望在 primary 不稳定时能够读取
secondary，通过牺牲部分强一致性来降低读请求的长尾并提高系统的可用性。backup request 便是用来实现此功能的。
# 设计实现
-backup reqeust的实现原理比较简单：对于读操作（目前写操作不支持backup
request），当client向primary发送请求后，如果经过一段时间延时（通常是p999）其response仍然没有返回，则随机选择一台secondary并向其发送backup
request。最后获取最快返回来的response进行处理。
+backup request 的实现原理比较简单：对于读操作（目前写操作不支持 backup request），当 client 向 primary
发送请求后，如果经过一段时间延迟（通常是 p999）其 response 仍然没有返回，则随机选择一台 secondary 并向其发送 backup
request。最后获取最快返回的 response 进行处理。
-这里发送secondary请求的延时我们建议选择p999，因为backup
request操作是用来实现消除长尾的，并不是提升集群性能的。如果将该值设置过低，则会由于backup
request的请求量过大而导致集群压力增大（假设选择p50作为其延时，这样便会有50%的请求向secondary发送请求，系统负载便会增大50%）。
+这里发送 secondary 请求的延迟我们建议选择 p999，因为 backup request
操作是用来消除长尾的，并不是提升集群性能的。如果将该值设置过低，则会由于 backup request 的请求量过大而导致集群压力增大（假设选择 p50
作为其延迟，这样便会有 50% 的请求向 secondary 发送请求，系统负载便会增大 50%）。
# 如何使用
-在Pegasus java client v2.0.0中，我们增加了一个接口，通过该接口可以打开某个表的backup reqeust功能。其实现如下：
+在 Pegasus Java client v2.0.0 中，我们增加了一个接口，通过该接口可以打开某个表的 backup request 功能。其实现如下：
```java
public PegasusTableInterface openTable(String tableName, int
backupRequestDelayMs) throws PException;
```
-相比于老版本的`openTable`接口，我们增加了一个`backupRequestDelayMs`参数。这个参数便是上文所指的时延，即：向primary发送请求，如果过了`backupRequestDelayMs`毫秒response仍没有返回，则向secondary发送backup
request。需要注意的是，`backupRequestDelayMs <= 0`代表禁用backup reqeust功能。
+相比于老版本的 `openTable` 接口，我们增加了一个 `backupRequestDelayMs` 参数。这个参数便是上文所指的时延，即：向
primary 发送请求，如果过了 `backupRequestDelayMs` 毫秒 response 仍没有返回，则向 secondary 发送
backup request。需要注意的是，`backupRequestDelayMs <= 0` 代表禁用 backup request 功能。
-另外在老版本的`openTable`接口中，backup request功能默认是关闭的。
+另外在老版本的 `openTable` 接口中，backup request 功能默认是关闭的。
-# 性能测试
+# Benchmark
-下面表格里展示了是否打开backup request的性能对比，这里我们选取了未打开backup request时读请求的p999时间作为backup
request的delay时间(138ms)。数据显示，打开backup
request之后get请求的p999时延**基本没有变化**，而p9999时延却有了**数倍的降低**。
+下面表格里展示了是否打开 backup request 的性能对比，这里我们选取了未打开 backup request 时读请求的 p999 时间作为
backup request 的 delay 时间（138ms）。数据显示，打开 backup request 之后 get 请求的 p999
时延**基本没有变化**，而 p9999 时延却有了**数倍的降低**。
-另外，由于delay时间设置的是p999时间，大约1000个请求里只有1个请求会发送backup request，因此额外请求量（也就是开启backup
request的额外开销）比例在0.1%左右。依此类推，若想要降低P999时延，则可以将 `backupRequestDelayMs`
设置为P99延迟，由此会增加1%的额外读流量。
-
-| test case | enable backup request | read p9999 |
-| ---- | ---- | ---- |
-| 3-clients 15-threads | no | 988671 |
-| 3-clients 15-threads | yes| 153599 |
+另外，由于 delay 时间设置的是 p999 时间，大约 1000 个请求里只有 1 个请求会发送 backup
request，因此额外请求量（也就是开启 backup request 的额外开销）比例在 0.1% 左右。依此类推，若想要降低 P999 时延，则可以将
`backupRequestDelayMs` 设置为 P99 延迟，由此会增加 1% 的额外读流量。
+| test case | enable backup request | read p9999 latency in
microsecond |
+|----------------------|-----------------------|-----------------------------------|
+| 3-clients 15-threads | no | 988,671
|
+| 3-clients 15-threads | yes | 153,599
|
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
