当前位置:Gxlcms > mysql > SQLITE与ACCESS性能简单测试

SQLITE与ACCESS性能简单测试

时间:2021-07-01 10:21:17 帮助过:104人阅读

这段时间在做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较慢的写入速度应该是拉低插入速度的原因。

人气教程排行