构建测试用例 ， 能够进行功能测试和压力测试 。

[lijiang2014]

功能测试 ， 能测试出核心功能的可用性，需要逐渐添加

• 出错重算机制正常 simpletest
  - [ ] 批重算机制正常
  压力测试，能测试出系统的承压能力
• 测试任务规模 百万级任务测试
  - [ ] 测试节点规模 上千节点任务测试 移到V2， Pack 模式之中
  性能测试
• 性能损失测试
• 对1.0 最终版本进行 1M 测试

[lijiang2014]

- [ ] 危险测试 ， 测试节点崩溃，内存占用过大，等等极端情况。等worker 管理模块完善后进行。
移动到新需求中

[lijiang2014]

百万任务测试通过，使用了101个节点，耗时 1098 s ; 平均单个任务耗时 2.6352 cpu-s（1098 × 100 × 24 / 1000000） ， 基本为调度耗时。
这个性能还需要优化。
实际问题可能更加严重，实际任务只进行到 111922 后面的计算出错了。

redis.exceptions.ConnectionError: Error 104 while writing to socket. Connection reset by peer.
是redis 故障？

[lijiang2014]

测试发现，一些worker 会失去连接：

[2016-12-20 15:20:49,836: ERROR/Worker-24] Connection to Redis lost: Retry (14/20) in 1.00 second.

而成功列表一直没有更新

[nscc-gz_jiangli@cn4684%tianhe2-C ~]$ /WORK/app/redis/3.2.4/bin/redis-cli -h cn4684
cn4684:6379> LLEN success_list
(integer) 43801
cn4684:6379> LLEN fail_list
(integer) 0
cn4684:6379> LLEN retry_list
(integer) 0
cn4684:6379> LLEN success_list
(integer) 43801
cn4684:6379> 

[lijiang2014]

可能是redis client 数量限制 ： maxclients 4064 的问题 。
4064/24 = 169.333 ? 不应该呀 。
可能是暂时的网络问题导致的worker 失败 ？
可能需要更复杂的worker 的管理 ？
srun 导致的失败？

[lijiang2014]

所以需要对worker 的状态 ， Nodes 的状态进行监控 ， 如果有问题的话得进行相应的处理。

[lijiang2014]

[nscc-gz_jiangli@ln2%tianhe2-C ctest_m]$ /WORK/app/redis/3.2.4/bin/redis-cli -h cn5876
cn5876:6379> LLEN celery
(error) ERR max number of clients reached
cn5876:6379>
还真到上限了 ！

[lijiang2014]

目前推测单任务的调度耗时为 4 s ; 可使用的节点规模在 50 ～ 100 之间 （24 worker / Nodes）
后续要针对性能和规模进行更多的优化。

[lijiang2014]

通过复用 redis 连接， 减少连接数的占用，应该可以提高并发数量：

 class HtcTask(Task):
- def __init__(self):
-
- thht_port = int( os.getenv( "THHT_PORT", 6379 ) )
- thht_host = os.getenv( "THHT_HOST", None )
- if not thht_host :
- raise Exception("Error: No THHT_HOST SET")
- self.redis_instance = redis.Redis( host= thht_host , port = thht_port )
def on_success(self, retval, task_id, args, kwargs):
task_info = {'task_id': task_id,
'retval': retval,}
- self.redis_instance.lpush('success_list', task_info)
+ self.backend.client.lpush('success_list', task_info)

[lijiang2014]

50（+1） 节点的测试 ：

Tue Dec 20 16:23:56 CST 2016
cn5790
['/WORK/app/thht/thht/config.py', 'settings.htc']
EXEC = ./ctest
INPUT =  input.htc
queue.max_retries = 2
queue.default_retry_delay = 0
run.py
2016-12-20 16:24:07
All task pushed into queue
2016-12-20 16:39:21
Get All result
2016-12-20 16:40:23
Tue Dec 20 16:40:25 CST 2016

16:23:56 任务开始执行
16:24:07 主提交程序 run.py 开始运行
16:39:21 所有的任务被推到队列
16:40:23 所有的任务处理完成
16:40:25 所有程序退出
则 ：
准备环境 耗时 11s
推到队列 耗时 914s (计算也在进行)
队列清空 耗时 62s
退出环境 耗时 2s

可以看到，目前将任务推到队列花了比较多的时间，不知道是不是受到了消息流速的限制？
此测试的平均时耗为 1.17s (1.18s) ; 属于可接受也可优化的范畴。

[lijiang2014]

默认没有 rate_limit .

task_default_rate_limit

Default: No rate limit.

The global default rate limit for tasks.

This value is used for tasks that doesn’t have a custom rate limit

看来主要还是调度开销。不过这部分开销应该可以被计算掩盖掉。后面测试下掩盖的效果即可。

[lijiang2014]

解决了连接数的问题后，100（+1）节点的测试如下：
14:24:17 开始
14:24:28 进入主体
14:39:51 全部进入队列
14:40:52 全部完成
14:40:54 退出
则 ：
准备环境 耗时 11s
推到队列 耗时 923s (计算也在进行)
队列清空 耗时 61s
退出环境 耗时 2s
和50节点的测试基本一致。

其他地方的优化没有效果，主要耗时还是在：
rest = run_command.delay(cmd )
这个可以并行进行，但必要性不高。

[lijiang2014]

性能损失 ：
环境的准备和退出 ： 13s
提交一个任务 ： 0.923ms (可掩盖)

[lijiang2014]

头节点性能： 对于百万级任务。进度63%时， redis-server 占用 1.3 GB ， python 占用 0.8 GB ， 总约 2GB ；因后续程序还会有更复杂功能的添加，目测支持 千万级任务没有问题。
受 系统 ulimt open files 4096 的限制 ， 如果跑满 24 个 worker , 则只能 少于 170 个节点的批作业，但如果Pack 模式 可以成功，则可以突破这个限制，使最大节点规模达到4000 。 如果要处理更大的规模，则必须要修改系统ulimt

[lijiang2014]

运行略大于 3s 的 task :

14:51:49
14:52:03  14s
15:07:12   909s
15:13:39   387s
15:13:40   1s 

单任务耗时为 3.11s , 没有被掩盖的耗时大概只有 0.1s