这段时间在做CMS(客户管理系统,不是内容管理)的访问管理功能,要求实现对服务提供设备,客户端,计费,权限认证等信息的存储统计,远程管理。要求系统发布要方便,远程管理软件要跑在WIN平台。考虑到系统规模,客户要求,最后选择了WINACCESS的方案,而最
这段时间在做CMS(客户管理系统,不是内容管理)的访问管理功能,要求实现对服务提供设备,客户端,计费,权限认证等信息的存储统计,远程管理。要求系统发布要方便,远程管理软件要跑在WIN平台。考虑到系统规模,客户要求,最后选择了WIN+ACCESS的方案,而最近又发现一个免费的SQLITE,而且可能在以后的手持设备上用,花点时间做了如下的简单性能测试。
ACCESS 插入性能测试:
平台:SYS:WINXP;CPU:2*1.6GHZ;RAM:1G;APP:VC+ADO
1.单条显式事务:
1 00条: 0.55S
1000条: 5s
10000条: 50s
2.单条非显式事务:
100条:31ms
1000条:156ms
10000条:1500ms
3.批量事务:
1 00条:16ms
1000条:141ms
10000条:1469ms
以上可以看出,ACCESS单条非显式事务插入的时间几乎和批量事务的插入时间一样。但是,单条非显式事务的
方式只能用单连接,如果有多个连接并发访问,则会出现严重问题,在一个链接插入后的相当长一段时间内(有时数S),其它链接都无法插入数据库。可以推理
ADO+ACCESS是采用了一种类似CACHE的做法缓存了操作,但是却一直锁住数据库。单条的显式事务可以保证多链接的访问,但是速度会慢很多,下面再对比一下
SQLITE的测试性能;
SQLITE PC平台插入性能测试:
平台:SYS:WINXP+VMWARE+FEDORA7(LINUX2.6.21);CPU;1.6GHZ;RAM:412M; APP:C+SQLITE
1.单条显式事务(SQLITE默认为每个操作开启事务)
100条:0.587s
1000条:6.962s
10000条:56.004s
2.批量事务
100条:81ms(可能误差较大)
1000条:124ms
10000条:1257ms
SQLITE 嵌入式平台插入性能测试:
平台:SYS:LINUX2.6.14;CPU:HI3512 ARM9 200MHZ级别;RAM:32M,ROM:32M NOR FLASH;APP:C+SQLITE
1.单条显式事务(SQLITE默认为每个操作开启事务)
100条:1.98s
1000条:19.97s
10000条:34.63s
2.批量事务
100条:0.15s
1000条:0.89s
10000条:8.24s
在ARM+LINUX的平台,NOR FLASH较慢的写入速度应该是拉低插入速度的原因。