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
然后導入數(shù)據(jù)（
INFO_GSM, BILL_DATA
，
USER_SPECIAL_NUMBER
）【來源于
172.18.1.30
數(shù)據(jù)庫】
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
（唯一值查詢條件）
以上初略的數(shù)據(jù)可以看出來（服務器響應慢），其速度比普通磁盤數(shù)據(jù)庫是高出至少一個數(shù)量級的。
<
二
>
代碼測試（效率上基本不存在問題，主要是安全性能測試）
自編代碼測試：
FTP::172.18.34.168\/data0/ibas/jianguoh/fastdb/examples/FastdbTest.cpp
源碼如右：
數(shù)據(jù)庫文件：
FTP::172.18.34.168\/data0/ibas/jianguoh/fastdb/ FastdbTest.fdb
1、
Complex and Large transaction processing
多次對于大規(guī)模的數(shù)據(jù)進行增，刪，查，改后進行事務處理，沒有發(fā)現(xiàn)異常。（跑的測試代碼）
(
先查詢，然后更改，然后插入部分記錄，最后再有選擇地刪除部分數(shù)據(jù)
)
2、
Concurrent transaction’s Safe
Concurrent Threads can run safely in my lots of tests!(
一
Update
模式進程和大量
ReadOnly
模式線程（同一個進程）并發(fā)操作
)
<
三
>
因為對于開源代碼測試我們沒有任何規(guī)范和流程，測試只能夠依靠測試者自己當時的想法和定義來測
附：
本來就很好的內(nèi)存機制，再加上多種高性能的查詢優(yōu)化技術，其效率應該是沒什么問題了。
以下是一國外文獻上更翔實直觀的深度效率測試報告圖：（其中
MS-SQL
指的是
Microsoft SQL
Server
2000
磁盤數(shù)據(jù)庫
）
