IBM AIX 服务器上
<
一
>
利用
SUBSQL
接口手工进行测试
----------<Some test Data>-----------------------------------------
1.Record(int4,char const*)
dbDatabase db(dbDatabase::dbAllAccess, 16*1024); // 96Mb page pool
Insert 50000 records,elapsed time: 1 seconds
Insert 100000 records,elapsed time: 2 seconds
insert 1000000 records,elapsed time: 9 seconds
Insert 10000000 records,elapsed time: 120 seconds
dbDatabase db(dbDatabase::dbAllAccess, 160*1024); // 960Mb page pool
Insert 50000 records,elapsed time: 1 seconds
Insert 100000 records,elapsed time: 1 seconds
Insert 1000000 records,elapsed time: 8 seconds
Insert 10000000 records,elapsed time: 124 seconds
dbDatabase db(dbDatabase::dbAllAccess, 160*1024); // 960Mb page pool
db.setConcurrency(10);
Insert 10000000 records,elapsed time: 116 seconds
然后导入数据（
INFO_GSM, BILL_DATA
，
USER_SPECIAL_NUMBER
）【来源于
172.18.1.30
数据库】
Update 100000 records,elapsed time: 1 seconds
Update 1000000 records,elapsed time: 9 seconds
Query 1000000 records,elapsed time: 2 seconds
（多重查询条件）
Query 10000000 records,elapsed time: 1 seconds
（唯一值查询条件）
以上初略的数据可以看出来（服务器响应慢），其速度比普通磁盘数据库是高出至少一个数量级的。
<
二
>
代码测试（效率上基本不存在问题，主要是安全性能测试）
自编代码测试：
FTP::172.18.34.168\/data0/ibas/jianguoh/fastdb/examples/FastdbTest.cpp
源码如右：
数据库文件：
FTP::172.18.34.168\/data0/ibas/jianguoh/fastdb/ FastdbTest.fdb
1、
Complex and Large transaction processing
多次对于大规模的数据进行增，删，查，改后进行事务处理，没有发现异常。（跑的测试代码）
(
先查询，然后更改，然后插入部分记录，最后再有选择地删除部分数据
)
2、
Concurrent transaction’s Safe
Concurrent Threads can run safely in my lots of tests!(
一
Update
模式进程和大量
ReadOnly
模式线程（同一个进程）并发操作
)
<
三
>
因为对于开源代码测试我们没有任何规范和流程，测试只能够依靠测试者自己当时的想法和定义来测
附：
本来就很好的内存机制，再加上多种高性能的查询优化技术，其效率应该是没什么问题了。
以下是一国外文献上更翔实直观的深度效率测试报告图：（其中
MS-SQL
指的是
Microsoft SQL
Server
2000
磁盘数据库
）
