JPPF试用日记

最近根据项目需要，我们试用了JPPF（Java并行处理框架）2.1.1。JPPF非常容易使用，根据相关文档我们很快的就运行起来了，下面是试用过程中对一些相关问题的纪录和思考：

1、有的节点早就完成任务了，有的节点却要仍在运行中，造成负载不均衡。
解决方法：server配置中注释掉  jppf.load.balancing.algorithm = proportional  一句，使其使用默认的负载均衡策略，才可以做到根据任务情况动态分配（需要深入研究几种任务分配策略的差异），否则任务会一次性分配完成而不再调整。

2、节点数量的确定：
节点配置文件里有配置处理线程数的地方，但经过测试没有效果，通过任务管理器资源情况分析，每个节点只能启动一个处理线程，不知道是不是bug。所以，一个物理机器需要启动多个节点才能充分利用CPU资源，最大节点数与CPU核心数大体相当即可。

实测情况：每个任务1万次蒙特卡洛模拟，共100个任务
1）、服务端  8CPUs（双核x4），7-8个Node可使CPU利用率达到100%
2）、PC客户端 2CPUs（双核单CPU），启动1个Node仅使用50%左右，启动2个Node可达100%

注意：在CPU100%利用情况下，服务器上曾经出现一个任务死锁的情况（最后一个任务长时间不结束）

3、启用本地计算的说明：
经实测， client启用本地计算后，仅有50%的任务会提交server执行，另50%任务本地执行，且后续不会动态调整分配比例，使本地执行时间成为瓶颈。

建议不要启用client本地计算，如果想充分利用client本地计算资源，可以在本地启动Node连接同一个Server即可。

4、实测发现，蒙特卡洛模拟计算任务的执行时间与CPU主频有关，实测中PC（Core2 E7400 2.80GHz）每核心的处理能力要优于服务器（Xeon E5410 2.33GHz），服务器上一个节点处理10个任务的时间PC可以处理13个，所以廉价PC处理此类任务时的性价比非常高。

针对我们开发的原型程序，有一组数据可以说明JPPF的价值：

相同任务情况下：
• PC单线程不使用JPPF，用时33分钟；
• PC作客户端+服务器启动6节点，用时9分钟；
• PC作客户端并启动2节点+服务器启动6节点，用时7分钟。
在资源充足的前提下，计算时间与节点数成反比。

还挺强大的吗，学习

其实Hadoop更强大，只是不容易用。