博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
SharePoint 2013 列表关于大数据的測试<二>
阅读量:2232 次
发布时间:2019-05-09

本文共 1738 字,大约阅读时间需要 5 分钟。

  1、给測试列表加入查阅项字段,100个,代码例如以下:

  2、插入測试数据的方法,注意查阅项字段的格式,代码例如以下:

  3、插入10w条数据,时间花费例如以下(不建议List[LISTNAME].Items.Add。会比較慢):

  4、查看列表设置,数据有10w条,阙值设置500w。例如以下图:

  5、进入AllItems页面。发现查阅项字段数大于限制(8个),例如以下图:

  6、改动查阅项限制数目(改动为500),例如以下图:

  7、数据量10w,查阅项字段100个时的測试数据,例如以下表格:

  表一:分页30,LookUp字段50;

视图项目数

LookUp字段数

翻页时间

30

50

17s

   

15s

   

15s

   

15s

   

14s

  表二:分页100,LookUp字段50。

视图项目数

LookUp字段数

翻页时间

100

50

42s

   

44s

   

43s

   

42s

   

43s

  表三:分页30,LookUp字段15;

视图项目数

LookUp字段数

翻页时间

30

15

5.09s

   

5.69s

   

5.10s

   

5.52s

   

5.32s

  表四:分页100,LookUp字段15。

视图项目数

LookUp字段数

翻页时间

100

15

13s

   

14s

   

14s

   

14s

   

14s

  表五:分页30。LookUp字段8(默认阙值为8)。

视图项目数

LookUp字段数

翻页时间

30

8

3.13s

   

2.82s

   

3.08s

   

3.78s

   

2.94s

  表六:分页100,LookUp字段8(默认阙值为8);

视图项目数

LookUp字段数

翻页时间

100

8

5.35s

   

5.54s

   

7.46s

   

7.80s

   

8.10s

  表七:分页300,LookUp字段8(默认阙值为8)。

视图项目数

LookUp字段数

翻页时间

300

8

16.48s

   

17.13s

   

17.30s

   

17.52s

   

17.59s

  8、插入10w数据,单行文本字段100个。插入时间例如以下图:

  9、数据量10w,单行文本字段100个时的測试数据,例如以下表格:

  表八:分页500,Text字段100;

视图项目数

Text字段数

翻页时间

500

100

7.22s

   

6.28s

   

7.10s

   

6.81s

   

5.76s

  表九:分页1K。Text字段100。

  分页为1k的时候,页面已经非常卡。载入非常慢了。

视图项目数

Text字段数

翻页时间

1000

100

14.20s

   

14.51s

   

21.37s

   

25.99s

   

23.61s

  表十:分页1K。Text字段1;

视图项目数

Text字段数

翻页时间

1000

1

2.81s

   

2.96s

   

2.92s

   

2.72s

   

2.89s

  10、插入測试数据100w,单行文本字段数100。插入时间例如以下图:

  11、数据量100w。单行文本字段数100。測试数据例如以下表格:

  表十一:分页1K,Text字段1。

视图项目数

Text字段数

翻页时间

1000

1

2.78s

   

3.04s

   

2.90s

   

2.95s

   

2.91s

  表十二:分页500。Text字段100;

视图项目数

Text字段数

翻页时间

500

100

7.15s

   

7.35s

   

6.91s

   

7.24s

   

7.25s

  表十三:分页100,Text字段100;

视图项目数

Text字段数

翻页时间

100

100

1.96s

   

1.76s

   

1.68s

   

1.54s

   

1.61s

结 论

  通过上面的測试数据。个人觉得LookUp字段是查询时间花费最长的。而单行文本应该属于查询时间花费较少的一类,所以查询效率和列表内项目数关系不大(未超过列表阙值。100w级别内),和单次查询数量、视图中字段数、视图中字段类型关系非常大。

总 结

  通过上面的測试,个人觉得SharePoint列表处理百万级别的数据。应该说压力不大,由于数据插入速度较慢,稍后会測试更大数量级别。和断开权限时列表效率等问题,有关数据可參考兴许博客。

  

转载于:https://www.cnblogs.com/ljbguanli/p/6871833.html

你可能感兴趣的文章
Spring源码剖析5:JDK和cglib动态代理原理详解
查看>>
Spring源码剖析6:Spring AOP概述
查看>>
分布式系统理论基础1: 一致性、2PC和3PC
查看>>
分布式系统理论基础3: 时间、时钟和事件顺序
查看>>
分布式系统理论基础4:Paxos
查看>>
分布式系统理论基础5:选举、多数派和租约
查看>>
分布式系统理论基础6:Raft、Zab
查看>>
分布式系统理论基础8:zookeeper分布式协调服务
查看>>
搞懂分布式技术1:分布式系统的一些基本概念
查看>>
搞懂分布式技术2:分布式一致性协议与Paxos,Raft算法
查看>>
搞懂分布式技术6:Zookeeper典型应用场景及实践
查看>>
搞懂分布式技术10:LVS实现负载均衡的原理与实践
查看>>
搞懂分布式技术11:分布式session解决方案与一致性hash
查看>>
搞懂分布式技术12:分布式ID生成方案
查看>>
搞懂分布式技术13:缓存的那些事
查看>>
搞懂分布式技术14:Spring Boot使用注解集成Redis缓存
查看>>
搞懂分布式技术15:缓存更新的套路
查看>>
搞懂分布式技术16:浅谈分布式锁的几种方案
查看>>
搞懂分布式技术17:浅析分布式事务
查看>>
搞懂分布式技术18:分布式事务常用解决方案
查看>>