jndi+rmi+proxool应用负载下的远程数据源1（原创）

引：最近在做网游账号充值系统，工作中遇到个问题。由于pv较高，用了10台服务器做应用的负载，负载方式简单轮询（猜的，没问过系统，呵呵）。应用都需要和数据库交互，每个应用都配置了自己的proxool池，平分了dba给的连接数。这里假设dba只分给我们50个连接，那么平均到每个应用，就是10个连接。这就面临个问题，负载是针对pv的，不知道当前请求是否操作数据库，因此可能出现有的应用需要超过10个连接，而有的应用空闲着链接。造成链接的浪费。而且如果日后还需要加应用服务器，或者数据库端口ip变更，需要修改每个应用的proxool.xml。

考虑了一下，希望能将数据源独立出来，放到1台服务器。其他应用都到这个服务器拿链接。写了点代码，很快发现，connection很难做到序列化。放弃！
看了看我们目前的数据库查询及更新，用的都是存储过程和预编译sql。就是那种一堆???的方式。既然不能把链接拿到应用服务器，那应用服务器就把sql发送给数据源创建链接，然后通过jndi和rmi，在应用服务器上远程调用这个链接。客户端只是些接口文件，服务端利用工厂创建链接。处理后，再利用CachedRowSet序列化传给客户端。

实现了，跑了一下效率，很不理想。
-----------------------

1 服务器直接读取数据库
查询结果1000条，用时：5652
查询结果1000条，用时：6106
查询结果1000条，用时：5675

2 我本地访问服务器上的远程数据源，数据源再访问数据库
查询结果1000条，用时：68547
获得factory对象用时：5139
获得connection对象用时：15272
获得resultSet对象用时：39757

查询结果1000条，用时：70266
获得factory对象用时：5869
获得connection对象用时：14483
获得resultSet对象用时：40494

查询结果1000条，用时：70250
获得factory对象用时：5089
获得connection对象用时：17709
获得resultSet对象用时：39266

3 服务器项目访问服务器远程数据源，数据源再访问数据库（通信时间最小化）
查询结果1000条，用时：49061
获得factory对象用时：869
获得connection对象用时：7391
获得resultSet对象用时：38308

查询结果1000条，用时：45443
获得factory对象用时：839
获得connection对象用时：6814
获得resultSet对象用时：35593

查询结果1000条，用时：45532
获得factory对象用时：728
获得connection对象用时：6681
获得resultSet对象用时：35843
-----------------------



时间主要消耗在resultset序列化上。虽说客户端能直接操作resultset很方便，但是没效率，就没有可行性。而我们的应用多以查一条数据或几个字段为主，只好放弃resultset序列化，转而rmi直接返回所需数据。当然resultset序列化的方式保留，以备不时之需。
取消resultset序列化后的效率

-----------------------

更正一下，1000条指的是同一条sql，执行1000次。
针对resultset序列化速度问题，取消了序列化。改为调用远程对象，从resultset直接取值。牺牲了灵活性，获取了一定的效率提升。
理论最小访问时间是普通方式的170.28%我本地访问时间是普通方式的430.35%时间受到服务器性能的影响。日后考虑在缓存常用sql上做优化。
附件中是全部文件，有兴趣的可以看看，提点宝贵建议，咱们一起讨论，谢谢。

以下为测试结果：

1 服务器直接读取数据库
查询结果1000条，用时：5171
查询结果1000条，用时：5190
查询结果1000条，用时：5313

2 我本地访问服务器上的远程数据源，数据源再访问数据库
查询结果1000次，用时：22359
获得factory对象用时：2377
获得connection对象用时：12437
设置参数，执行，获取结果，释放连接用时：7545

查询结果1000次，用时：22375
获得factory对象用时：2165
获得connection对象用时：12086
设置参数，执行，获取结果，释放连接用时：8124

查询结果1000次，用时：22719
获得factory对象用时：2348
获得connection对象用时：12365
设置参数，执行，获取结果，释放连接用时：8006

3 服务器项目访问服务器远程数据源，数据源再访问数据库（通信时间最小化）
查询结果1000次，用时：9200
获得factory对象用时：647
获得connection对象用时：6713
设置参数，执行，获取结果，释放连接用时：1822

查询结果1000次，用时：8660
获得factory对象用时：528
获得connection对象用时：6523
设置参数，执行，获取结果，释放连接用时：1592

查询结果1000次，用时：8830
获得factory对象用时：538
获得connection对象用时：6654
设置参数，执行，获取结果，释放连接用时：1619
-----------------------



效率有一定的提升，但是我期望远程数据源的方式，能比普通方式更快，能做到么？当然可以。就像超市统一配送一样，远程数据源掌握着大量的链接，而我们的应用使用了预编译sql，因此数量有限，所以建立个池保存常用sql的链接。如果一个请求是常用sql，那么直接从池里拿链接。

-----------------------
从上次性能优化的结果上可以看出，主要消耗时间是获取connection对象这块。
思考了一下远程数据源相较普通方式，存在着一个优势：连接数统一管理。
Pro连接池有最小连接数的概念，这部分链接是长连接，始终链接数据库。
由此考虑到能否将这些链接利用起来。普通方式，每个连接池的最小连接数可能也就几个。
但是如果统一管理连接数，那个最小连接数就会增加n倍。以账号为例，dba给我们分配的连接数是50，那我们可以将远程数据源的最小连接数设为20。
实际上我们常用的sql并不多。这20个连接保存常用sql的链接，需要时，直接从池中拿取，不用再链接数据库。以提升效率。

理论最小访问时间是普通方式的56.52%（理论上可以做到比普通方式更快）
我本地访问时间是普通方式的272.49%

效率优化到现在，个人认为这个方案还是可行的。

以下为测试结果：

1 服务器直接读取数据库
查询结果1000条，用时：5271
查询结果1000条，用时：5266
查询结果1000条，用时：5180

2 我本地访问服务器上的远程数据源，数据源再访问数据库
查询结果1000次，用时：14156
获得factory对象用时：156
获得connection对象用时：4631
设置参数，执行，获取结果，释放连接用时：9369

查询结果1000次，用时：14812
获得factory对象用时：156
获得connection对象用时：4885
设置参数，执行，获取结果，释放连接用时：9771

查询结果1000次，用时：13860
获得factory对象用时：157
获得connection对象用时：4454
设置参数，执行，获取结果，释放连接用时：9249

3 服务器项目访问服务器远程数据源，数据源再访问数据库（通信时间最小化）
查询结果1000次，用时：3011
获得factory对象用时：0
获得connection对象用时：661
设置参数，执行，获取结果，释放连接用时：2343

查询结果1000次，用时：2854
获得factory对象用时：1
获得connection对象用时：735
设置参数，执行，获取结果，释放连接用时：2108

查询结果1000次，用时：3018
获得factory对象用时：1
获得connection对象用时：594
设置参数，执行，获取结果，释放连接用时：2418

-----------------------


理论上远程数据源可以比普通方式速度更快。目前已经做了简单测试合并法，马上就要找个项目试试啦。
哈哈，估计实际应用后，问题很多，rmi通信直接受到网速影响，丢包等等。
不过找个双网服务器，应该问题不大。有问题在解决呗！