Merge pull request #62 from wangguibao/ctr_model_serving

Add entries for newly added configure options

doc/SERVING_CONFIGURE.md

@@ -18,9 +18,8 @@ services {
 
 其中
 
-port: 该字段标明本机serving实例启动的监听端口。默认为8010。还可以通过--port=8010命令行参数指定。
-
-services: 可以配置多个services。Paddle Serving被设计为单个Serving实例可以同时承载多个预测服务，服务间通过service name进行区分。例如以下代码配置2个预测服务：
+- port: 该字段标明本机serving实例启动的监听端口。默认为8010。还可以通过--port=8010命令行参数指定。
+- services: 可以配置多个services。Paddle Serving被设计为单个Serving实例可以同时承载多个预测服务，服务间通过service name进行区分。例如以下代码配置2个预测服务：
 ```JSON
 port: 8010
 services {
@@ -33,7 +32,7 @@ services {
 }
 ```
 
-service.name: 请填写serving/proto/xx.proto文件的service名称，例如，在serving/proto/image_class.proto中，service名称如下声明：
+- service.name: 请填写serving/proto/xx.proto文件的service名称，例如，在serving/proto/image_class.proto中，service名称如下声明：
 ```JSON
 service ImageClassifyService {
   rpc inference(Request) returns (Response);
@@ -43,11 +42,11 @@ service ImageClassifyService {
 ```
 则service name就是`ImageClassifyService`
 
-service.workflows: 用于指定该service下所配的workflow列表。可以配置多个workflow。在本例中，为`ImageClassifyService`配置了一个workflow：`workflow1`。`workflow1`的具体定义在workflow.prototxt
+- service.workflows: 用于指定该service下所配的workflow列表。可以配置多个workflow。在本例中，为`ImageClassifyService`配置了一个workflow：`workflow1`。`workflow1`的具体定义在workflow.prototxt
 
 ## 2. workflow.prototxt
 
-workflow.prototxt用来描述每一个具体的workflow，他的protobuf格式可参考`configure/server_configure.protobuf`的`Workflow`类型。具体的磁盘文件路径可通过--workflow_path和--workflow_file指定。一个例子如下：
+workflow.prototxt用来描述每一个具体的workflow，他的protobuf格式可参考`configure/server_configure.protobuf`的`Workflow`类型。具体的磁盘文件路径可通过`--workflow_path`和`--workflow_file`指定。一个例子如下：
 
 ```JSON
 workflows {
@@ -86,32 +85,32 @@ workflows {
 ```
 以上样例配置了2个workflow：`workflow1`和`workflow2`。以`workflow1`为例：
 
-name: workflow名称，用于从service.prototxt索引到具体的workflow
-
-workflow_type: 可选"Sequence", "Parallel"，表示本workflow下节点所代表的OP是否可并行。**当前只支持Sequence类型，如配置了Parallel类型，则该workflow不会被执行**
-
-nodes: 用于串联成workflow的所有节点，可配置多个nodes。nodes间通过配置dependencies串联起来
-
-node.name: 随意，建议取一个能代表当前node所执行OP的类
-
-node.type: 当前node所执行OP的类名称，与serving/op/下每个具体的OP类的名称对应
-
-node.dependencies: 依赖的上游node列表
-
-node.dependencies.name: 与workflow内节点的name保持一致
-
-node.dependencies.mode: RO-Read Only, RW-Read Write
+- name: workflow名称，用于从service.prototxt索引到具体的workflow
+- workflow_type: 可选"Sequence", "Parallel"，表示本workflow下节点所代表的OP是否可并行。**当前只支持Sequence类型，如配置了Parallel类型，则该workflow不会被执行**
+- nodes: 用于串联成workflow的所有节点，可配置多个nodes。nodes间通过配置dependencies串联起来
+- node.name: 随意，建议取一个能代表当前node所执行OP的类
+- node.type: 当前node所执行OP的类名称，与serving/op/下每个具体的OP类的名称对应
+- node.dependencies: 依赖的上游node列表
+- node.dependencies.name: 与workflow内节点的name保持一致
+- node.dependencies.mode: RO-Read Only, RW-Read Write
 
 # 3. resource.prototxt
 
-Serving端resource配置的入口是resource.prototxt，用于配置模型信息。它的protobuf格式参考`configure/proto/server_configure.proto`的ResourceConf。具体的磁盘文件路径可用--resource_path和--resource_file指定。样例如下：
+Serving端resource配置的入口是resource.prototxt，用于配置模型信息。它的protobuf格式参考`configure/proto/server_configure.proto`的ResourceConf。具体的磁盘文件路径可用`--resource_path`和`--resource_file`指定。样例如下：
 
 ```JSON
-model_manager_path: ./conf
-model_manager_file: model_toolkit.prototxt
+model_toolkit_path: "./conf"
+model_toolkit_file: "model_toolkit.prototxt"
+cube_config_file: "./conf/cube.conf"
 ```
 
-主要用来指定model_toolkit.prototxt路径
+其中：
+
+- model_toolkit_path:用来指定model_toolkit.prototxt所在的目录
+- model_toolkit_file: 用来指定model_toolkit.prototxt所在的文件名
+- cube_config_file: 用来指定cube配置文件所在路径与文件名
+
+Cube是Paddle Serving中用于大规模稀疏参数的组件。
 
 # 4. model_toolkit.prototxt
 
@@ -127,14 +126,15 @@ engines {
   runtime_thread_num: 0
   batch_infer_size: 0
   enable_batch_align: 0
+  sparse_param_service_type: LOCAL
+  sparse_param_service_table_name: "local_kv"
 }
 ```
 
 其中
 
-name: 模型名称。InferManager通过此名称，找到要使用的模型和预测引擎。可参考serving/op/classify_op.h与serving/op/classify_op.cpp的InferManager::instance().infer()方法的参数来了解。
-
-type: 预测引擎的类型。可在inferencer-fluid-cpu/src/fluid_cpu_engine.cpp找到当前注册的预测引擎列表
+- name: 模型名称。InferManager通过此名称，找到要使用的模型和预测引擎。可参考serving/op/classify_op.h与serving/op/classify_op.cpp的InferManager::instance().infer()方法的参数来了解。
+- type: 预测引擎的类型。可在inferencer-fluid-cpu/src/fluid_cpu_engine.cpp找到当前注册的预测引擎列表
 
 |预测引擎|含义|
 |--------|----|
@@ -152,9 +152,8 @@ type: 预测引擎的类型。可在inferencer-fluid-cpu/src/fluid_cpu_engine.cp
 
 Analysis API在模型加载过程中，会对模型计算逻辑进行多种优化，包括但不限于zero copy tensor，相邻OP的fuse等。**但优化逻辑不是一定对所有模型都有加速作用，有时甚至会有反作用，请以实测结果为准**。
 
-reloadable_meta: 目前实际内容无意义，用来通过对该文件的mtime判断是否超过reload时间阈值
-
-reloadable_type: 检查reload条件：timestamp_ne/timestamp_gt/md5sum/revision/none
+- reloadable_meta: 目前实际内容无意义，用来通过对该文件的mtime判断是否超过reload时间阈值
+- reloadable_type: 检查reload条件：timestamp_ne/timestamp_gt/md5sum/revision/none
 
 |reloadable_type|含义|
 |---------------|----|
@@ -163,13 +162,19 @@ reloadable_type: 检查reload条件：timestamp_ne/timestamp_gt/md5sum/revision/
 |md5sum|目前无用，配置后永远不reload|
 |revision|目前无用，配置后用于不reload|
 
-model_data_path: 模型文件路径
-
-runtime_thread_num: 若大于0， 则启用bsf多线程调度框架，在每个预测bthread worker内启动多线程预测。要注意的是，当启用worker内多线程预测，workflow中OP需要用Serving框架的BatchTensor类做预测的输入和输出 (predictor/framework/infer_data.h, `class BatchTensor`)。
+- model_data_path: 模型文件路径
+- runtime_thread_num: 若大于0， 则启用bsf多线程调度框架，在每个预测bthread worker内启动多线程预测。要注意的是，当启用worker内多线程预测，workflow中OP需要用Serving框架的BatchTensor类做预测的输入和输出 (predictor/framework/infer_data.h, `class BatchTensor`)。
+- batch_infer_size: 启用bsf多线程预测时，每个预测线程的batch size
+- enable_batch_align:
+- sparse_param_service_type: 枚举类型，可选参数，大规模稀疏参数服务类型
 
-batch_infer_size: 启用bsf多线程预测时，每个预测线程的batch size
+|sparse_param_service_type|含义|
+|-------------------------|--|
+|NONE|不使用大规模稀疏参数服务|
+|LOCAL|单机本地大规模稀疏参数服务，以rocksdb作为引擎|
+|REMOTE|分布式大规模稀疏参数服务，以Cube作为引擎|
 
-enable_batch_align:
+- sparse_param_service_table_name: 可选参数，大规模稀疏参数服务承载本模型所用参数的表名。
 
 ## 5. 命令行配置参数