diff --git a/java-chassis-reference/en_US/transports/rest-over-vertx.md b/java-chassis-reference/en_US/transports/rest-over-vertx.md
index 7b3e111..7a802cc 100644
--- a/java-chassis-reference/en_US/transports/rest-over-vertx.md
+++ b/java-chassis-reference/en_US/transports/rest-over-vertx.md
@@ -47,6 +47,25 @@
 | servicecomb.rest.client.connection.compression         | false                                          | Wether the client support compression          |
 | servicecomb.rest.client.maxHeaderSize                  | 8192                                           | The max header size of the response the client can process, unit is Byte |
 
+### Supplementary Explanation
+
+* The connection amount under extreme condition
+  Assumption:
+  * servicecomb.rest.client.thread-count = 8
+  * servicecomb.rest.client.connection.maxPoolSize = 5
+  * there are 10 instances of microservice A  
+
+  In terms of client side, under the extreme condition:
+  * for a client instance invoking microservice A, there are up to 400 connections.(`8 * 5 * 10 = 400`)
+  * if this client instance is also invoking another microservice B, and there are 10 instances of microservice B, then there are another 400 connections, and 800 connections in total.
+
+  In terms of server side, under the extreme condition:
+  * a client instance establishes up to 40 connections to a server instance.(`8 * 5 = 40`)
+  * `n` client instances establish up to `40 * n` connections to a server instance.
+
+  To improve performance, larger connection pools are needed. While the larger connection pools means the more connections. When the microservice instance scale reaches hundreds, some instances may handle tens of thousands of connections. Therefore, the developers need to make reasonable planning according to the actual condition.
+  The planning of HTTP1.1 may be relatively complex, and sometimes there is no proper solution, in which case the [http2](transports/http2.md) is recommended.
+
 ## Sample Code
 
 An example of the configuration in the microservice.yaml file for REST over Vertx:
diff --git a/java-chassis-reference/zh_CN/transports/rest-over-vertx.md b/java-chassis-reference/zh_CN/transports/rest-over-vertx.md
index a21371d..8847046 100644
--- a/java-chassis-reference/zh_CN/transports/rest-over-vertx.md
+++ b/java-chassis-reference/zh_CN/transports/rest-over-vertx.md
@@ -52,15 +52,15 @@
   * 微服务A有10个实例  
 
   站在client的角度，在极限情况下：
-  * 一个client调用微服务A，最多会建立400条连接。（8 * 5 * 10 = 400）  
+  * 一个client调用微服务A，最多会建立400条连接。（`8 * 5 * 10 = 400`）  
   * 假设该client还需要调用微服务B，微服务B，也有10个实例，则最多再建立400条连接，共800条连接
 
   站在server的角度，在极限情况下：
-  * 一个client最多向一个server建立40条连接。(8 * 5 = 40)  
-  * n个client最多会向一个server建立40 * n条连接
+  * 一个client最多向一个server建立40条连接。(`8 * 5 = 40`)  
+  * `n`个client最多会向一个server建立`40 * n`条连接
 
   为了提高性能，需要尽量使用更大的连接池，但是更大的连接池又可能会导致连接数暴涨，当微服务实例规模达到百级别时，有的进程可能需要管理几万条连接，业务需要根据实际业务规模进行合理的规划。  
-  http1.1的规划相对复杂，并且有的场景几乎无解，建议切换为[http2](transports/http2.md)
+  http1.1的规划相对复杂，并且有的场景几乎无解，建议切换为[http2](transports/http2.md)。
 
 ## 示例代码