Update Official Docs

doc/Offical_Docs/3-2_QuickStart_Pipeline_OCR_CN.md

@@ -17,7 +17,7 @@ PaddleOCR 提供的 PP-OCR 系列模型覆盖轻量级服务端、轻量级移
 | 中英文通用服务端模型 | 143.4M | ch_ppocr_server_v2.0_xx | 服务器端 |
 
 
-## 模型步骤
+## 部署步骤
 
 前提条件是你已完成[环境安装]()步骤，并已验证环境安装成功，此处不在赘述。
 
@@ -155,7 +155,6 @@ op:
             #min_subgraph_size: 3
 ```
 
-
 **四.代码与配置信息绑定 **
 第四步，实现代码和配置文件 Config.yml 绑定，以及设置多模型组合关系。具体包括：
 
@@ -202,6 +201,40 @@ ocr_service.run_service()
 
 **五.启动服务与验证**
 
+启动服务前，可看到程序路径下所有文件路径如下：
+```
+.
+├── 7.jpg
+├── benchmark.py
+├── benchmark.sh
+├── config.yml
+├── imgs
+│   └── ggg.png
+├── ocr_det_client
+│   ├── serving_client_conf.prototxt
+│   └── serving_client_conf.stream.prototxt
+├── ocr_det_model
+│   ├── inference.pdiparams
+│   ├── inference.pdmodel
+│   ├── serving_server_conf.prototxt
+│   └── serving_server_conf.stream.prototxt
+├── ocr_rec_client
+│   ├── serving_client_conf.prototxt
+│   └── serving_client_conf.stream.prototxt
+├── ocr_rec_model
+│   ├── inference.pdiparams
+│   ├── inference.pdmodel
+│   ├── serving_server_conf.prototxt
+│   └── serving_server_conf.stream.prototxt
+├── pipeline_http_client.py
+├── pipeline_rpc_client.py
+├── ppocr_keys_v1.txt
+├── ProcessInfo.json
+├── README_CN.md
+├── README.md
+└── web_service.py
+```
+
 运行程序 `web_service.py` 启动服务端
 ```
 # Run Server

doc/Offical_Docs/7-0_Python_Pipeline_Int_CN.md

@@ -8,5 +8,5 @@ Python Pipeline 使用案例请阅读[Python Pipeline 快速部署案例](./3-2_
 
 通过阅读以下内容掌握 Python Pipeline 核心功能和使用方法、高阶功能用法和性能优化指南等。
 - [Python Pipeline 框架设计](7-1_Python_Pipeline_Design_CN.md)
-- [Python Pipeline 高阶用法](7-2_Python_Pipeline_Senior_CN.md)
+- [Python Pipeline 核心功能](7-2_Python_Pipeline_Senior_CN.md)
 - [Python Pipeline 优化指南](7-3_Python_Pipeline_Optimize_CN.md)

doc/Offical_Docs/7-1_Python_Pipeline_Design_CN.md

-# Python Pipeline 核心功能
+# Python Pipeline 框架设计
 
 为了解决多个深度学习模型组合的复杂问题，Paddle Serving 团队设计了一个通用端到端多模型组合框架，其核心特点包括:
 
@@ -58,6 +58,17 @@ ocr_service.prepare_pipeline_config("config.yml")
 ocr_service.run_service()
 ```
 
+与网络框架相关的配置在 `config.yml` 中设置。其中 `worker_num` 表示框架主线程 gRPC 线程池工作线程数，可理解成网络同步线程并发数。
+
+其次，`rpc_port` 和 `http_port` 是服务端口，可同时开启，不允许同时为空。
+```
+worker_num: 10
+
+# http 和 gRPC 服务端口
+rpc_port: 9988
+http_port: 18089
+```
+
 
 **二.图执行引擎层**
 
@@ -135,6 +146,28 @@ Pipeline 服务日志在当前目录的 `PipelineServingLogs` 目录下，有3
 - `pipeline.log.wf` : 记录 warning & error日志
 - `pipeline.tracer` : 统计各个阶段耗时、channel 堆积信息
 
+```
+├── config.yml
+├── get_data.sh
+├── PipelineServingLogs
+│   ├── pipeline.log
+│   ├── pipeline.log.wf
+│   └── pipeline.tracer
+├── README_CN.md
+├── README.md
+├── uci_housing_client
+│   ├── serving_client_conf.prototxt
+│   └── serving_client_conf.stream.prototxt
+├── uci_housing_model
+│   ├── fc_0.b_0
+│   ├── fc_0.w_0
+│   ├── __model__
+│   ├── serving_server_conf.prototxt
+│   └── serving_server_conf.stream.prototxt
+├── web_service_java.py
+└── web_service.py
+```
+
 在服务发生异常时，错误信息会记录在 pipeline.log.wf 日志中。打印 tracer 日志要求在 config.yml 的 DAG 属性中添加 tracer 配置。
 
 1. 日志与请求的唯一标识
@@ -177,8 +210,42 @@ Pipeline 的日志模块在 `logger.py` 中定义，使用了 `logging.handlers.
 
 ```
 
-**四. 服务超时与重试**
+**四. 错误信息**
+
+框架提供的错误信息如下所示， 完整信息在 `error_catch.py` 中 `CustomExceptionCode` 类中定义。
+
+| 错误码 |  说明  |
+| :---: | :-------------: |
+| 0   |  成功 |
+| 50 ~ 999 | 产品错误 |
+| 3000 ~ 3999 | 框架内部服务错误 |
+| 4000 ~ 4999 | 配置错误  |
+| 5000 ~ 5999 | 用户输入错误  |
+| 6000 ~ 6999 | 超时错误 | 
+| 7000 ~ 7999 | 类型检查错误 |
+| 8000 ~ 8999 | 内部通讯错误 |
+| 9000 ~ 9999 | 推理错误 |
+| 10000 ~     | 其他错误 |
 
+具体错误信息如下：
+
+```
+class CustomExceptionCode(enum.Enum): 
+    OK = 0
+    PRODUCT_ERROR = 50
+
+    NOT_IMPLEMENTED = 3000
+    CLOSED_ERROR = 3001
+    NO_SERVICE = 3002
+    INIT_ERROR = 3003
+    CONF_ERROR = 4000
+    INPUT_PARAMS_ERROR = 5000
+    TIMEOUT = 6000
+    TYPE_ERROR = 7000
+    RPC_PACKAGE_ERROR = 8000 
+    CLIENT_ERROR = 9000
+    UNKNOW = 10000
+```
 
 
 ## 自定义信息

doc/Offical_Docs/7-2_Python_Pipeline_Senior_CN.md

-# Python Pipeline 高阶用法
+# Python Pipeline 核心功能
 
-在复杂业务场景中使用常规功能无法满足需求，本文介绍一些高阶用法。
-- DAG 结构跳过某个 Op 运行
+从设计上，Python Pipeline 框架实现轻量级的服务化部署，提供了丰富的核心功能，既能满足服务基本使用，又能满足特性需求。
+
+- 安装与环境检查
+- 服务启动与关闭
+- 本地与远程推理
 - 批量推理
 - 单机多卡推理
 - 多种计算芯片上推理
-- 低精度推理
 - TensorRT 推理加速
 - MKLDNN 推理加速
+- 低精度推理
+- 复杂图结构 DAG 跳过某个 Op 运行
 
+## 安装与环境检查
+在运行 Python Pipeline 服务前，确保当前环境下可部署且通过[安装指南](./2-0_Index_CN.md)已完成安装。其次，`v0.8.0`及以上版本提供了环境检查功能，检验环境是否安装正确。
 
-**一.DAG 结构跳过某个 Op 运行**
+输入以下命令，进入环境检查程序。
+```python
+python3 -m paddle_serving_server.serve check
+```
 
-此应用场景一般在 Op 前后处理中有 if 条件判断时，不满足条件时，跳过后面处理。实际做法是在跳过此 Op 的 process 阶段，只要在 preprocess 做好判断，跳过 process 阶段，在和 postprocess 后直接返回即可。
-preprocess 返回结果列表的第二个结果是 `is_skip_process=True` 表示是否跳过当前 Op 的 process 阶段，直接进入 postprocess 处理。
+在环境检验程序中输入多条指令来检查，例如 `check_pipeline`，`check_all`等，完整指令列表如下。
+
+| 指令 | 描述|
+|---------|----|
+|check_all | 检查 Paddle Inference、Pipeline Serving、C++ Serving。只打印检测结果，不记录日志|
+|check_pipeline | 检查 Pipeline Serving，只打印检测结果，不记录日志|
+|check_cpp | 检查 C++ Serving，只打印检测结果，不记录日志|
+|check_inference | 检查 Paddle Inference 是否安装正确，只打印检测结果，不记录日志|
+|debug | 发生报错后，该命令将打印提示日志到屏幕，并记录详细日志文件|
+|exit | 退出|
 
-```python
-## Op::preprocess() 函数实现
-def preprocess(self, input_dicts, data_id, log_id):
-    """
-    In preprocess stage, assembling data for process stage. users can 
-    override this function for model feed features.
-    Args:
-        input_dicts: input data to be preprocessed
-        data_id: inner unique id
-        log_id: global unique id for RTT
-    Return:
-        input_dict: data for process stage
-        is_skip_process: skip process stage or not, False default
-        prod_errcode: None default, otherwise, product errores occured.
-                      It is handled in the same way as exception. 
-        prod_errinfo: "" default
-    """
-    # multiple previous Op
-    if len(input_dicts) != 1:
-        _LOGGER.critical(
-            self._log(
-                "Failed to run preprocess: this Op has multiple previous "
-                "inputs. Please override this func."))
-        os._exit(-1)
-    (_, input_dict), = input_dicts.items()
-    return input_dict, False, None, ""
+
+程序会分别运行 cpu 和 gpu 示例。运行成功则打印 `Pipeline cpu environment running success
+` 和 `Pipeline gpu environment running success`。
 
 ```
-以下示例 Jump::preprocess() 重载了原函数，返回了 True 字段
+/usr/local/lib/python3.7/runpy.py:125: RuntimeWarning: 'paddle_serving_server.serve' found in sys.modules after import of package 'paddle_serving_server', but prior to execution of 'paddle_serving_server.serve'; this may result in unpredictable behaviour
+  warn(RuntimeWarning(msg))
+Welcome to the check env shell.Type help to list commands.
+
+(Cmd) check_pipeline
+Pipeline cpu environment running success
+Pipeline gpu environment running success
+```
+
+运行失败时，错误信息会记录到当前目录下 `stderr.log` 文件 和 `Pipeline_test_cpu/PipelineServingLogs` 目录下。用户可根据错误信息调试。 
+
+```
+(Cmd) check_all
+PaddlePaddle inference environment running success
+C++ cpu environment running success
+C++ gpu environment running failure, if you need this environment, please refer to https://github.com/PaddlePaddle/Serving/blob/develop/doc/Install_CN.md
+Traceback (most recent call last):
+  File "/usr/local/lib/python3.7/runpy.py", line 193, in _run_module_as_main
+    "__main__", mod_spec)
+  File "/usr/local/lib/python3.7/runpy.py", line 85, in _run_code
+    exec(code, run_globals)
+  File "/usr/local/lib/python3.7/site-packages/paddle_serving_server/serve.py", line 541, in <module>
+    Check_Env_Shell().cmdloop()
+  File "/usr/local/lib/python3.7/cmd.py", line 138, in cmdloop
+    stop = self.onecmd(line)
+  File "/usr/local/lib/python3.7/cmd.py", line 217, in onecmd
+    return func(arg)
+  File "/usr/local/lib/python3.7/site-packages/paddle_serving_server/serve.py", line 501, in do_check_all
+    check_env("all")
+  File "/usr/local/lib/python3.7/site-packages/paddle_serving_server/env_check/run.py", line 94, in check_env
+    run_test_cases(pipeline_test_cases, "Pipeline", is_open_std)
+  File "/usr/local/lib/python3.7/site-packages/paddle_serving_server/env_check/run.py", line 66, in run_test_cases
+    mv_log_to_new_dir(new_dir_path)
+  File "/usr/local/lib/python3.7/site-packages/paddle_serving_server/env_check/run.py", line 48, in mv_log_to_new_dir
+    shutil.move(file_path, dir_path)
+  File "/usr/local/lib/python3.7/shutil.py", line 555, in move
+    raise Error("Destination path '%s' already exists" % real_dst)
+shutil.Error: Destination path '/home/work/Pipeline_test_cpu/PipelineServingLogs' already exists
+
+```
+
+## 服务启动与关闭
+
+服务启动需要三类文件，PYTHON 程序、模型文件和配置文件。以[Python Pipeline 快速部署案例](./3-2_QuickStart_Pipeline_OCR_CN.md)为例，
+```
+.
+├── config.yml
+├── imgs
+│   └── ggg.png
+├── ocr_det_client
+│   ├── serving_client_conf.prototxt
+│   └── serving_client_conf.stream.prototxt
+├── ocr_det_model
+│   ├── inference.pdiparams
+│   ├── inference.pdmodel
+│   ├── serving_server_conf.prototxt
+│   └── serving_server_conf.stream.prototxt
+├── ocr_det.tar.gz
+├── ocr_rec_client
+│   ├── serving_client_conf.prototxt
+│   └── serving_client_conf.stream.prototxt
+├── ocr_rec_model
+│   ├── inference.pdiparams
+│   ├── inference.pdmodel
+│   ├── serving_server_conf.prototxt
+│   └── serving_server_conf.stream.prototxt
+├── pipeline_http_client.py
+├── pipeline_rpc_client.py
+├── ppocr_keys_v1.txt
+└── web_service.py
+```
+
+启动服务端程序运行 `web_service.py`，启动客户端程序运行 `pipeline_http_client.py` 或 `pipeline_rpc_client.py`。服务端启动的日志信息在 `PipelineServingLogs` 目录下可用于调试。
+```
+├── PipelineServingLogs
+│   ├── pipeline.log
+│   ├── pipeline.log.wf
+│   └── pipeline.tracer
+```
+
+关闭程序可使用2种方式，
+- 前台关闭程序：`Ctrl+C` 关停服务
+- 后台关闭程序：
 ```python
-class JumpOp(Op):
-    ## Overload func JumpOp::preprocess
-    def preprocess(self, input_dicts, data_id, log_id):
-        (_, input_dict), = input_dicts.items()
-        if input_dict.has_key("jump"):
-            return input_dict, True, None, ""
-        else
-            return input_dict, False, None, ""
+python3 -m paddle_serving_server.serve stop   # 触发 SIGINT 信号
+python3 -m paddle_serving_server.serve kill   # 触发 SIGKILL 信号，强制关闭
+```
+
+## 本地与远程推理
+
+本地推理是指在服务所在机器环境下开启多进程推理，而远程推理是指本地服务请求远程 C++ Serving 推理服务。
+
+本地推理的优势是实现简单，一般本地处理相比于远程推理耗时更低。而远程推理的优势是可实现 Python Pipeline 较难实现的功能，如部署加密模型，大模型推理。
+
+Python Pipeline 的本地推理可参考如下配置，在 `uci` op 中 增加 `local_service_conf` 配置，并设置 `client_type: local_predictor`。
+```
+op:
+    uci:
+        #并发数，is_thread_op=True时，为线程并发；否则为进程并发
+        concurrency: 10
+
+        #当op配置没有server_endpoints时，从local_service_conf读取本地服务配置
+        local_service_conf:
+
+            #uci模型路径
+            model_config: uci_housing_model
+
+            #计算硬件类型: 空缺时由devices决定(CPU/GPU)，0=cpu, 1=gpu, 2=tensorRT, 3=arm cpu, 4=kunlun xpu
+            device_type: 0
+
+            #计算硬件ID，优先由device_type决定硬件类型。devices为""或空缺时为CPU预测；当为"0", "0,1,2"时为GPU预测，表示使用的GPU卡
+            devices: "" # "0,1"
+
+            #client类型，包括brpc, grpc和local_predictor.local_predictor不启动Serving服务，进程内预测
+            client_type: local_predictor
+
+            #Fetch结果列表，以client_config中fetch_var的alias_name为准
+            fetch_list: ["price"]
 ```
 
+Python Pipeline 的远程推理可参考如下配置，设置 `client_type: brpc`，`server_endpoints`，`timeout` 和本地 `client_config`。
+
+```
+op:
+    bow:
+        #并发数，is_thread_op=True时，为线程并发；否则为进程并发
+        concurrency: 1
+    
+        #client连接类型，brpc
+        client_type: brpc
+
+        #Serving交互重试次数，默认不重试
+        retry: 1
+
+        #Serving交互超时时间, 单位ms
+        timeout: 3000
+
+        #Serving IPs
+        server_endpoints: ["127.0.0.1:9393"]
+
+        #bow模型client端配置
+        client_config: "imdb_bow_client_conf/serving_client_conf.prototxt"
+
+        #Fetch结果列表，以client_config中fetch_var的alias_name为准
+        fetch_list: ["prediction"]
+```
 
-**二. 批量推理**
+## 批量推理
 
 Pipeline 支持批量推理，通过增大 batch size 可以提高 GPU 利用率。Python Pipeline 支持3种 batch 形式以及适用的场景如下：
 - 场景1：客户端打包批量数据(Client Batch)
 - 场景2：服务端合并多个请求动态合并批量(Server auto-batching)
-- 场景3：服务端拆分一个批量数据推理请求成为多个小块推理(Server mini-batch)
+- 场景3：拆分一个大批量的推理请求为多个小批量推理请求(Server mini-batch)
 
 
-1. 客户端打包批量数据
+**一.客户端打包批量数据**
 
 当输入数据是 numpy 类型，如shape 为[4, 3, 512, 512]的 numpy 数据，即4张图片，可直接作为输入数据。
 当输入数据的 shape 不同时，需要按最大的shape的尺寸 Padding 对齐后发送给服务端
 
-2. 服务端合并多个请求动态合并批量
+**二.服务端合并多个请求动态合并批量**
+
 有助于提升吞吐和计算资源的利用率，当多个请求的 shape 尺寸不相同时，不支持合并。当前有2种合并策略，分别是：
 
 - 等待时间与最大批量结合（推荐）：结合`batch_size`和`auto_batching_timeout`配合使用，实际请求的批量条数超过`batch_size`时会立即执行，不超过时会等待`auto_batching_timeout`时间再执行
@@ -119,9 +248,9 @@ op:
 
 ```
 
+**三.Mini-Batch**
 
-
-3.服务端拆分一个批量数据推理请求成为多个小块推理：会降低批量数据 Padding 对齐的大小，从而提升速度。可参考 [OCR 示例]()，核心思路是拆分数据成多个小批量，放入 list 对象 feed_list 并返回
+拆分一个批量数据推理请求成为多个小块推理：会降低批量数据 Padding 对齐的大小，从而提升速度。可参考 [OCR 示例]()，核心思路是拆分数据成多个小批量，放入 list 对象 feed_list 并返回
 
 ```
 def preprocess(self, input_dicts, data_id, log_id):
@@ -181,8 +310,7 @@ def preprocess(self, input_dicts, data_id, log_id):
         return feed_list, False, None, ""
 ```
 
-
-**三. 单机多卡推理**
+## 单机多卡推理
 
 单机多卡推理与 `config.yml` 中配置4个参数关系紧密，`is_thread_op`、`concurrency`、`device_type` 和 `devices`，必须在进程模型和 GPU 模式，每张卡上可分配多个进程，即 M 个 Op 进程与 N 个 GPU 卡绑定。
 ```
@@ -218,8 +346,7 @@ op:
 
 对于更灵活的进程与 GPU 卡绑定方式，会持续开发。
 
-
-**四. 多种计算芯片上推理**
+## 多种计算芯片上推理
 
 除了支持 CPU、GPU 芯片推理之外，Python Pipeline 还支持在多种计算硬件上推理。根据 `config.yml` 中的 `device_type` 和 `devices`来设置推理硬件和加速库如下：
 - CPU(Intel) : 0
@@ -232,27 +359,94 @@ op:
 
 当不设置`device_type`时，根据 `devices` 来设置，即当 `device_type` 为 "" 或空缺时为 CPU 推理；当有设定如"0,1,2"时，为 GPU 推理，并指定 GPU 卡。
 
-以使用 GPU 的编号为0和1号卡并开启 TensorRT 为例，TensorRT 要配合 `ir_optim` 一同开启，`config.yml`详细配置如下：
+以使用 XPU 的编号为0卡为例，配合 `ir_optim` 一同开启，`config.yml`详细配置如下：
 ```
 # 计算硬件类型
-device_type: 2
+device_type: 4
 
 # 计算硬件ID，优先由device_type决定硬件类型
-devices: "0,1"
+devices: "0"
 
 # 开启ir优化
 ir_optim: True
 
 ```
-           
-**五. 低精度推理**
-Pipeline Serving支持低精度推理，CPU、GPU和TensoRT支持的精度类型如下图所示：
 
+## TensorRT 推理加速
+
+TensorRT 是一个高性能的深度学习推理优化器，在 Nvdia 的 GPU 硬件平台运行的推理框架，为深度学习应用提供低延迟、高吞吐率的部署推理。
+
+通过设置`device_type`、`devices`和`ir_optim` 字段即可实现 TensorRT 高性能推理。必须同时设置 `ir_optim: True` 才能开启 TensorRT。
+
+```
+op:
+    imagenet:
+        #并发数，is_thread_op=True时，为线程并发；否则为进程并发
+        concurrency: 1
+
+        #当op配置没有server_endpoints时，从local_service_conf读取本地服务配置
+        local_service_conf:
+
+            #uci模型路径
+            model_config: serving_server/
+
+            #计算硬件类型: 空缺时由devices决定(CPU/GPU)，0=cpu, 1=gpu, 2=tensorRT, 3=arm cpu, 4=kunlun xpu
+            device_type: 2
+
+            #计算硬件ID，当devices为""或不写时为CPU预测；当devices为"0", "0,1,2"时为GPU预测，表示使用的GPU卡
+            devices: "1" # "0,1"
+
+            #client类型，包括brpc, grpc和local_predictor.local_predictor不启动Serving服务，进程内预测
+            client_type: local_predictor
+
+            #Fetch结果列表，以client_config中fetch_var的alias_name为准
+            fetch_list: ["score"]
+
+            #开启 ir_optim
+            ir_optim: True
+```
+
+## MKL-DNN 推理加速
 
+MKL-DNN 针对 Intel CPU 和 GPU 的数学核心库，对深度学习网络进行算子和指令集的性能优化，从而提升执行速度。Paddle 框架已集成了 MKL-DNN。
+
+目前仅支持 Intel CPU 推理加速，通过设置`device_type` 和 `devices` 和 `use_mkldnn` 字段使用 MKL-DNN。
+
+```
+op:
+    imagenet:
+        #并发数，is_thread_op=True时，为线程并发；否则为进程并发
+        concurrency: 1
+
+        #当op配置没有server_endpoints时，从local_service_conf读取本地服务配置
+        local_service_conf:
+
+            #uci模型路径
+            model_config: serving_server/
+
+            #计算硬件类型: 空缺时由devices决定(CPU/GPU)，0=cpu, 1=gpu, 2=tensorRT, 3=arm cpu, 4=kunlun xpu
+            device_type: 0
+
+            #计算硬件ID，当devices为""或不写时为CPU预测；当devices为"0", "0,1,2"时为GPU预测，表示使用的GPU卡
+            devices: ""
+
+            #client类型，包括brpc, grpc和local_predictor.local_predictor不启动Serving服务，进程内预测
+            client_type: local_predictor
+
+            #Fetch结果列表，以client_config中fetch_var的alias_name为准
+            fetch_list: ["score"]
+
+            #开启 MKLDNN
+            use_mkldnn: True
+```
+
+## 低精度推理
+
+Pipeline Serving支持低精度推理，CPU、GPU和TensoRT支持的精度类型如下图所示：
 
 低精度推理需要有量化模型，配合`config.yml`配置一起使用，以[低精度示例]() 为例
 
-1. CPU 低精度推理配置
+**一.CPU 低精度推理配置**
 
 通过设置，`device_type` 和 `devices` 字段使用 CPU 推理，通过调整`precision`、`thread_num`和`use_mkldnn`参数选择低精度和性能调优。
 
@@ -290,9 +484,9 @@ op:
             use_mkldnn: True
 ```
 
-2. GPU + TensorRT 低精度推理
+**二.GPU 和 TensorRT 低精度推理**
 
-通过设置，`device_type` 和 `devices` 字段使用原生 GPU 或 TensorRT 推理，通过调整`precision`、`ir_optim`和`use_calib`参数选择低精度和性能调优，如开启 TensorRT，必须一同开启`ir_optim`，`use_calib`仅配合 int8 使用。
+通过设置`device_type` 和 `devices` 字段使用原生 GPU 或 TensorRT 推理，通过调整`precision`、`ir_optim`和`use_calib`参数选择低精度和性能调优，如开启 TensorRT，必须一同开启`ir_optim`，`use_calib`仅配合 int8 使用。
 ```
 op:
     imagenet:
@@ -327,8 +521,7 @@ op:
             ir_optim: True
 ```
 
-
-3. 性能测试
+**三.性能测试**
 
 测试环境如下：
 - GPU 型号: A100-40GB
@@ -345,7 +538,6 @@ op:
 - GPU + int8 + ir_optim + TensorRT + use_calib : 15.1 ms
 - GPU + fp16 + ir_optim + TensorRT : 17.2 ms
 
-
 CPU 推理性能较好的配置是
 - CPU + bf16 + MKLDNN : 18.2 ms
 - CPU + fp32 + thread_num=10 : 18.4 ms
@@ -354,3 +546,48 @@ CPU 推理性能较好的配置是
 <div align=center>
 <img src='../images/low_precision_profile.png' height = "600" align="middle"/>
 </div
+
+## 复杂图结构 DAG 跳过某个 Op 运行
+
+此应用场景一般在 Op 前后处理中有 if 条件判断时，不满足条件时，跳过后面处理。实际做法是在跳过此 Op 的 process 阶段，只要在 preprocess 做好判断，跳过 process 阶段，在和 postprocess 后直接返回即可。
+preprocess 返回结果列表的第二个结果是 `is_skip_process=True` 表示是否跳过当前 Op 的 process 阶段，直接进入 postprocess 处理。
+
+```python
+## Op::preprocess() 函数实现
+def preprocess(self, input_dicts, data_id, log_id):
+    """
+    In preprocess stage, assembling data for process stage. users can 
+    override this function for model feed features.
+    Args:
+        input_dicts: input data to be preprocessed
+        data_id: inner unique id
+        log_id: global unique id for RTT
+    Return:
+        input_dict: data for process stage
+        is_skip_process: skip process stage or not, False default
+        prod_errcode: None default, otherwise, product errores occured.
+                      It is handled in the same way as exception. 
+        prod_errinfo: "" default
+    """
+    # multiple previous Op
+    if len(input_dicts) != 1:
+        _LOGGER.critical(
+            self._log(
+                "Failed to run preprocess: this Op has multiple previous "
+                "inputs. Please override this func."))
+        os._exit(-1)
+    (_, input_dict), = input_dicts.items()
+    return input_dict, False, None, ""
+
+```
+以下示例 Jump::preprocess() 重载了原函数，返回了 True 字段
+```python
+class JumpOp(Op):
+    ## Overload func JumpOp::preprocess
+    def preprocess(self, input_dicts, data_id, log_id):
+        (_, input_dict), = input_dicts.items()
+        if input_dict.has_key("jump"):
+            return input_dict, True, None, ""
+        else
+            return input_dict, False, None, ""
+```

doc/Offical_Docs/7-3_Python_Pipeline_Optimize_CN.md

 # Python Pipeline 优化指南
 
+通常，服务的性能优化是基于耗时分析，首先要掌握服务运行的各阶段耗时信息，从中找到耗时最长的性能瓶颈再做针对性优化。对于模型推理服务化不仅要关注耗时，由于 GPU 芯片昂贵，更要关注服务吞吐，从而提升 GPU 利用率实现降本增效。因此，模型推理服务化可总结为：
+- 优化响应时长
+- 优化服务吞吐
 
-## 如何通过 Timeline 工具进行优化
+经过分析和调优后，各个阶段实现整体服务的性能最优。
 
-为了更好地对性能进行优化，Python Pipeline 提供了 Timeline 工具，对整个服务的各个阶段时间进行打点。
+## 优化响应时长
 
-## 在 Server 端输出 Profile 信息
+首先，优化响应时长的主要思路首先要掌握各阶段耗时，并分析出性能瓶颈或者耗时占比较高的阶段，再针对性能瓶颈做专项优化。
 
-Server 端用 yaml 中的 `use_profile` 字段进行控制：
+Paddle Serving 提供2种耗时分析工具，`Pipeline Trace Tool` 和 `Pipeline Profile Tool`。2个工具的特点如下：
+- Pipeline Trace Tool : 统计服务端所有进程各个阶段的平均耗时，包括每个 `Op` 和 `Channel`，用于定量分析。
+- Pipeline Profile Tool : 是可视化 Trace View 工具，生成多进程并发效果图，用定性和定量分析执行和并发效果。
 
-```yaml
+** 一.Pipeline Trace Tool **
+
+`Pipeline Trace Tool` 统计每个 `Op` 和 `Channel` 中各阶段的处理耗时，
+
+开启方法在配置文件 `config.yml` 的 `dag` 区段内添加 `tracer` 字段，框架会每隔 `interval_s` 时间生成 Trace 信息。
+```
 dag:
-    use_profile: true
+    #op资源类型, True, 为线程模型；False，为进程模型
+    is_thread_op: True
+
+    #tracer, 跟踪框架吞吐，每个OP和channel的工作情况。无tracer时不生成数据
+    tracer:
+        #每次trace的时间间隔，单位秒/s
+        interval_s: 10
+```
+
+生成的 Trace 信息保存在 `./PipelineServingLogs/pipeline.tracer` 日志中。如下图所示
+```
+==================== TRACER ======================
+ Op(uci):
+         in[8473.507333333333 ms]：          # 等待前置 Channel 中数据放入 Op 的耗时，如长时间无请求，此值会变大
+         prep[0.6753333333333333 ms]         # 推理前处理 preprocess 阶段耗时 
+         midp[26.476333333333333 ms]         # 推理 process 阶段耗时
+         postp[1.8616666666666666 ms]        # 推理后处理 postprocess 阶段耗时
+         out[1.3236666666666668 ms]          # 后处理结果放入后置 channel 耗时
+         idle[0.9965882097324374]            # 框架自循环耗时，间隔 1 ms，如此值很大说明系统负载高，调度变慢
+ DAGExecutor:
+         Query count[30]                     # interval_s 间隔时间内请求数量 
+         QPS[27.35 q/s]                      # interval_s 间隔时间内服务 QPS 
+         Succ[1.0]                           # interval_s 间隔时间内请求成功率 
+         Error req[]                         # 异常请求信息
+         Latency:                
+                 ave[36.55233333333334 ms]   # 平均延时
+                 .50[8.702 ms]               # 50分位延时
+                 .60[8.702 ms]               # 60分位延时
+                 .70[92.346 ms]              # 70分位延时
+                 .80[92.346 ms]              # 70分位延时
+                 .90[92.346 ms]              # 90分位延时
+                 .95[92.346 ms]              # 95分位延时
+                 .99[92.346 ms]              # 99分位延时
+ Channel (server worker num[1]):
+         chl0(In: ['@DAGExecutor'], Out: ['uci']) size[0/0]  # 框架 RequestOp 与 uci Op 之间 Channel 中堆积请求数。此值较大，说明下游 uci Op 消费能力不足。
+         chl1(In: ['uci'], Out: ['@DAGExecutor']) size[0/0]  # uci Op 与 框架 ResponseOp 之间 Channel 中堆积的请求数。此值较大，说明下游 ReponseOp 消费能力不足。
+ ==================== TRACER ======================
 ```
 
-开启该功能后，Server 端在预测的过程中会将对应的日志信息打印到标准输出，为了更直观地展现各阶段的耗时，提供 Analyst 模块对日志文件做进一步的分析处理。
+** 二.Pipeline Profile Tool **
 
-使用时先将 Server 的输出保存到文件，以 `profile.txt` 为例，脚本将日志中的时间打点信息转换成 json 格式保存到 `trace` 文件，`trace` 文件可以通过 chrome 浏览器的 tracing 功能进行可视化。
+```
+dag:
+    #op资源类型, True, 为线程模型；False，为进程模型
+    is_thread_op: True
+    
+    #使用性能分析, 默认为 False，imeline性能数据，对性能有一定影响
+    use_profile: True,
+```
+
+开启后，Server 端在预测的过程中会将对应的日志信息打印到`标准输出`，为了更直观地展现各阶段的耗时，因此服务启动要使用如下命令：
+```
+python3.7 web_service.py > profile.txt 2>&1
+```
 
-```python
+服务接收请求后，输出 Profile 信息到 `profile.txt` 文件中。再粘贴如下代码到 `trace.py`， 使用框架提供 Analyst 模块对日志文件做进一步的分析处理。
+```
 from paddle_serving_server.pipeline import Analyst
 import json
 import sys
@@ -30,50 +89,88 @@ if __name__ == "__main__":
     analyst.save_trace(trace_filename)
 ```
 
-具体操作：打开 chrome 浏览器，在地址栏输入 `chrome://tracing/` ，跳转至 tracing 页面，点击 load 按钮，打开保存的 `trace` 文件，即可将预测服务的各阶段时间信息可视化。
+运行命令，脚本将日志中的时间打点信息转换成 json 格式保存到 `trace` 文件。
+```
+python3.7 trace.py
+```
+
+`trace` 文件可以通过 `chrome` 浏览器的 `tracing` 功能进行可视化。
+```
+打开 chrome 浏览器，在地址栏输入 chrome://tracing/ ，跳转至 tracing 页面，点击 load 按钮，打开保存的 trace 文件，即可将预测服务的各阶段时间信息可视化。
+```
+
+通过图示中并发请求的处理流程可观测到推理阶段的流水线状态，以及多个请求在推理阶段的`间隔`信息，进行优化。
 
-## 在 Client 端输出 Profile 信息
 
-Client 端在 `predict` 接口设置 `profile=True`，即可开启 Profile 功能。
+** 三. 降低响应时长优化思路 **
 
-开启该功能后，Client 端在预测的过程中会将该次预测对应的日志信息打印到标准输出，后续分析处理同 Server。
+根据 `Pipeline Trace Tool` 输出结果在不同阶段耗时长的问题，常见场景的优化方法如下：
+- Op 推理阶段(midp) 耗时长:
+  - 增加 Op 并发度
+  - 开启 auto-batching (前提是多个请求的 shape 一致)
+  - 若批量数据中某条数据的 shape 很大，padding 很大导致推理很慢，可参考 OCR 示例中 mini-batch 方法。
+  - 开启 TensorRT/MKL-DNN 优化
+  - 开启低精度推理
+- Op 前处理阶段(prep) 或 后处理阶段耗时长:
+  - 增加 OP 并发度
+  - 优化前后处理逻辑
+- in/out 耗时长（channel 堆积>5）
+  - 检查 channel 传递的数据大小，可能为传输的数据大导致延迟大。
+  - 优化传入数据，不传递数据或压缩后再传入
+  - 增加 Op 并发度
+  - 减少上游 Op 并发度
 
-## 分析方法
-根据 `pipeline.tracer` 日志中的各个阶段耗时，按以下公式逐步分析出主要耗时在哪个阶段。
+根据 `Pipeline Profile Tool` 输出结果优化流水行并发的效果
+- 增加 Op 并发度，或调整不同 Op 的并发度
+- 开启 auto-batching
+
+此外，还有一些优化思路，如将 CPU 处理较慢的过程转换到 GPU 上处理等，客户端与服务端传输较大数据时，可使用共享内存方式传递内存或显存地址等。
+
+## 优化服务吞吐
+
+服务的吞吐量受到多种多因素条件制约，如 Op 处理时长、传输数据耗时、并发数和 DAG 图结构等，可以将这些因素进一步拆解，当传输数据不是极端庞大的时候，最重要因素是流水线中`最慢 Op 的处理时长和并发数`。
 ```
-单 OP 耗时：
+Op 处理时长：
 op_cost = process(pre + mid + post) 
 
-OP 期望并发数：
-op_concurrency  = 单OP耗时(s) * 期望QPS
-
 服务吞吐量：
-service_throughput = 1 / 最慢OP的耗时 * 并发数
+service_throughput = 1 / 最慢 op_cost * 并发数
 
 服务平响：
 service_avg_cost = ∑op_concurrency 【关键路径】
 
-Channel 堆积：
-channel_acc_size = QPS(down - up) * time
-
 批量预测平均耗时：
 avg_batch_cost = (N * pre + mid + post) / N 
 ```
 
-## 优化思路
+优化吞吐的主要方法是 `增大 Op 并发数`、`自动批量` 和 `CPU 与 GPU 处理分离`
 
-根据长耗时在不同阶段，采用不同的优化方法.
-- OP 推理阶段(mid-process):
-  - 增加 OP 并发度
-  - 开启 auto-batching (前提是多个请求的 shape 一致)
-  - 若批量数据中某条数据的 shape 很大，padding 很大导致推理很慢，可使用 mini-batch
-  - 开启 TensorRT/MKL-DNN 优化
-  - 开启低精度推理
-- OP 前处理阶段(pre-process):
-  - 增加 OP 并发度
-  - 优化前处理逻辑
-- in/out 耗时长（channel 堆积>5）
-  - 检查 channel 传递的数据大小和延迟
-  - 优化传入数据，不传递数据或压缩后再传入
-  - 增加 OP 并发度
-  - 减少上游 OP 并发度
+**一.增加 Op 并发数**
+
+调整 Op 的并发数量通过设置 `is_thread_op: False` 进程类型 Op 和 `uci` Op 的 `concurrency` 字段
+```
+dag:
+    #op资源类型, True, 为线程模型；False，为进程模型
+    is_thread_op: False
+op:
+    uci:
+        #并发数，is_thread_op=True时，为线程并发；否则为进程并发
+        concurrency: 10
+```
+Op 的进程数量不是越大越好，受到机器 CPU 核数、内存和显存大小的限制，推荐设置 Op 的并发数不超过系统 CPU 核数。
+
+**二.自动批量**
+
+自动配量是增加吞吐的有一种方法，开启方式可参考[Python Pipeline 核心功能](./7-2_Python_Pipeline_Senior_CN.md#批量推理)
+
+**三.CPU 与 GPU 处理分离**
+
+在 `CV` 模型中，对图片或视频的前后处理成为主要瓶颈时，可考虑此方案，即将前后处理过程独立成一个 Op 并独立设置并发度。
+
+将 CPU 前后处理和 GPU 推理过程比例调整到服务最佳配比。以 OCR 为例，原有流水线设计为 `RequestOp -> DetOp -> RecOp -> ResponseOp`。
+
+根据耗时分析，`DetOp` 和 `RecOp` 的前处理耗时很长，因此，将2个模型前处理分离成独立 Op，最新的流水线设计为:
+
+`RequestOp -> PreDetOp -> DetOp -> PreRecOp -> RecOp -> ResponseOp`，并调大 `PreDetOp` 和 `PreRecOp`的并发度，从而获得 20% 的性能提升。
+
+由于增加了2次数据传递，单条请求的处理延时会增加。

doc/Offical_Docs/7-4_Python_Pipeline_Benchmark_CN.md

+本次提测的Serving版本，支持GPU预测，希望以此任务为例，对Paddle Serving支持GPU预测的性能给出测试数据。
+
+## 测试环境
+
+|          | GPU | 显存 | CPU | 内存 |
+|----------|---------|----------|----------------------------------------------|------|
+| Serving端 | 4x Tesla P4-8GB | 7611MiB | Intel(R) Xeon(R) Gold 5117 CPU @ 2.00GHz 48核 | 216G |
+| Client端  | 4x Tesla P4-8GB | 7611MiB | Intel(R) Xeon(R) Gold 5117 CPU @ 2.00GHz 48核 | 216G |
+
+使用单卡GPU，未开启TensorRT。
+模型：ResNet_v2_50
+
+## 性能指标 
+
+|model_name |thread_num |batch_size |CPU_util(%) |GPU_memory(mb) |GPU_util(%) |qps(samples/s) |total count |mean(ms) |median(ms) |80 percent(ms) |90 percent(ms) |99 percent(ms) |total cost(s) |each cost(s)|
+|:--|:--|:--|:--|:--|:--|:--|:--|:--|:--|:--|:--|:--|:--|:--
+|ResNet_v2_50 |1 |1 |2.2 |3327 |17.25 |17.633658869240787 |355 |56.428481238996476 |38.646728515625 |39.496826171875 |39.98369140625 |1273.1911083984373 |20.131953477859497 |20.033540725708008|
+|ResNet_v2_50 |1 |4 |2.7 |3617 |28.122 |53.50748430453522 |268 |74.71539215543378 |74.6181640625 |75.3138671875 |75.6051025390625 |77.85322998046874 |20.03458046913147 |20.024930953979492|
+|ResNet_v2_50 |1 |8 |1.7 |3877 |25.7869 |59.60582783086999 |150 |133.5897119140625 |132.7503662109375 |134.968310546875 |136.470703125 |140.79039062499996 |20.132259607315063 |20.03933620452881|
+|ResNet_v2_50 |1 |16 |7.0 |4777 |27.0175 |63.2627646819339 |80 |252.30162048339844 |251.8448486328125 |253.046630859375 |253.91142578125 |263.361640625 |20.233070850372314 |20.18476152420044|
+|ResNet_v2_50 |1 |32 |7.5 |6567 |38.532 |62.945314687348024 |40 |506.8969482421875 |507.3531494140625 |510.562353515625 |511.421240234375 |536.8068920898437 |20.335111618041992 |20.276386737823486|
+|ResNet_v2_50 |2 |1 |4.7 |6567 |49.4828 |50.40600094376044 |1010 |39.63352195815285 |39.5345458984375 |40.452880859375 |41.1375 |42.940522460937494 |20.037296772003174 |20.01696753501892|
+|ResNet_v2_50 |2 |4 |2.7 |6567 |44.4744 |83.4255836891382 |420 |95.38548002697172 |95.7069091796875 |97.599951171875 |98.098583984375 |102.39680908203125 |20.137707471847534 |20.03199553489685|
+|ResNet_v2_50 |2 |8 |2.2 |6567 |42.898 |91.3727510505176 |230 |174.89108568274457 |175.0452880859375 |175.82001953125 |176.7634033203125 |178.64064453125002 |20.13729453086853 |20.1132071018219|
+|ResNet_v2_50 |2 |16 |2.2 |6567 |45 |97.5591285698611 |124 |327.16720088835683 |328.6126708984375 |329.75185546875 |330.386962890625 |336.86397460937496 |20.336385011672974 |20.284939169883728|
+|ResNet_v2_50 |2 |32 |3.2 |6567 |59.5714 |100.70765418116333 |64 |633.9812698364258 |637.8568115234375 |648.103515625 |650.7439697265625 |659.2212915039062 |20.336090803146362 |20.28787398338318|
+|ResNet_v2_50 |4 |1 |3.1 |6567 |64.3333 |80.27845081929433 |1617 |49.56464230756223 |49.4873046875 |51.5537109375 |52.693408203125 |55.207568359374996 |20.142391681671143 |20.038144528865814|
+|ResNet_v2_50 |4 |4 |3.3 |6567 |70.4563 |136.62061939701394 |688 |116.51574919944586 |121.8629150390625 |129.8181640625 |133.384423828125 |142.69500732421875 |20.143372297286987 |20.041599333286285|
+|ResNet_v2_50 |4 |8 |3.0 |6567 |70.896 |158.46554975132275 |399 |201.30669079926378 |210.69775390625 |228.51748046875 |236.427294921875 |252.24822753906233 |20.143179416656494 |20.081032752990723|
+|ResNet_v2_50 |4 |16 |3.2 |6567 |66.3832 |156.4935247130092 |197 |407.6668608224937 |423.974609375 |450.368212890625 |464.45986328125 |482.93658203125 |20.141408443450928 |20.078101694583893|
+|ResNet_v2_50 |4 |32 |3.3 |6567 |72.4791 |162.01742190796557 |104 |785.5079204852765 |813.0341796875 |887.107958984375 |909.6556640625 |935.3334838867188 |20.541000843048096 |20.423666059970856|
+|ResNet_v2_50 |8 |1 |3.5 |6567 |93.977 |115.9749228558386 |2337 |68.5580409078145 |65.45849609375 |76.13930664062501 |83.542041015625 |91.45666015624998 |20.15090799331665 |20.028797417879105|
+|ResNet_v2_50 |8 |4 |4.2 |6567 |90.0952 |175.58748591910316 |889 |180.7330482920592 |170.5810546875 |218.99931640625 |240.06337890625002 |254.413759765625 |20.252012729644775 |20.084695398807526|
+|ResNet_v2_50 |8 |8 |2.6 |6567 |93.8693 |206.76595246418208 |526 |306.52158695119414 |303.043212890625 |321.0791015625 |350.5477294921875 |400.32452392578125 |20.351513147354126 |20.15437400341034|
+|ResNet_v2_50 |8 |16 |3.2 |6567 |85.7273 |205.31850043117367 |265 |614.1745522553066 |552.372314453125 |775.89169921875 |802.022607421875 |902.2763183593761 |20.650842428207397 |20.345011442899704|
+|ResNet_v2_50 |8 |32 |5.0 |6567 |89.8717 |219.8410273718835 |146 |1138.4533474020761 |1039.640869140625 |1364.289794921875 |1474.6744384765625 |1788.2614379882834 |21.251720190048218 |20.777225106954575|
+|ResNet_v2_50 |12 |1 |5.0 |6567 |89.4762 |110.00858327847862 |2218 |108.50048552943953 |103.015625 |121.09404296875003 |137.1392333984375 |151.80401123046872 |20.162063121795654 |20.055511037508648|
+|ResNet_v2_50 |12 |4 |4.1 |6567 |77.7619 |153.7824464757549 |779 |309.68895575507463 |285.585205078125 |378.07421875 |413.481640625 |424.70853515625 |20.262390613555908 |20.104551911354065|
+|ResNet_v2_50 |12 |8 |3.6 |6567 |72.6977 |165.36021780846013 |425 |571.1991590073529 |510.995849609375 |731.9383300781251 |747.6568359375 |757.304716796875 |20.56117272377014 |20.230452219645183|
+|ResNet_v2_50 |12 |16 |1.5 |6567 |76.2222 |189.6414991568285 |252 |987.7153136238219 |926.00390625 |1080.99130859375 |1249.4956298828126 |1434.4802392578124 |21.26116919517517 |20.74245794614156|
+|ResNet_v2_50 |12 |32 |2.8 |6567 |84.25 |203.868228281784 |138 |1811.640237559443 |1764.2760009765625 |1855.28046875 |2023.56826171875 |2586.8038134765625 |21.66105055809021 |20.834286351998646|
+|ResNet_v2_50 |16 |1 |4.8 |6567 |94.3333 |116.34927733312234 |2347 |136.7957122373642 |135.959716796875 |144.1568359375 |146.105517578125 |175.05707519531248 |20.172020435333252 |20.067057371139526|
+|ResNet_v2_50 |16 |4 |15.4 |6567 |83.6364 |160.59012047270738 |822 |393.3079394412447 |396.446533203125 |426.272216796875 |429.777734375 |564.1119360351562 |20.47448492050171 |20.206754431128502|
+|ResNet_v2_50 |16 |8 |6.8 |6567 |81.0233 |169.95774070621547 |437 |741.5512622684854 |751.521484375 |763.199169921875 |948.8041992187501 |1001.156142578125 |20.56981921195984 |20.254074171185493|
+|ResNet_v2_50 |16 |16 |3.5 |6567 |77.8706 |186.56600081516 |248 |1332.1007946383568 |1365.2745361328125 |1399.212255859375 |1432.4037353515625 |1771.4374853515626 |21.26861262321472 |20.64799252152443|
+|ResNet_v2_50 |16 |32 |4.3 |6567 |83.6371 |201.1293408638195 |140 |2419.3400198800223 |2561.09228515625 |2616.081103515625 |2642.0835205078124 |2883.8197412109366 |22.274224042892456 |21.169659316539764|