PERFORMANCE

• 1: HugeGraph BenchMark Performance
• 2: HugeGraph-API Performance
  • 2.1: v0.5.6 Stand-alone(RocksDB)
  • 2.2: v0.5.6 Cluster(Cassandra)
  • 2.3: v0.4.4
  • 2.4: v0.2
• 3: HugeGraph-Loader Performance
• 4: HugeGraph 0.4.4 Benchmark

1 - HugeGraph BenchMark Performance

1 测试环境

1.1 硬件信息

1.2 软件信息

1.2.1 测试用例

测试使用graphdb-benchmark，一个图数据库测试集。该测试集主要包含4类测试：

• Massive Insertion，批量插入顶点和边，一定数量的顶点或边一次性提交

• Single Insertion，单条插入，每个顶点或者每条边立即提交

• Query，主要是图数据库的基本查询操作：

  • Find Neighbors，查询所有顶点的邻居
  • Find Adjacent Nodes，查询所有边的邻接顶点
  • Find Shortest Path，查询第一个顶点到100个随机顶点的最短路径

• Clustering，基于Louvain Method的社区发现算法

1.2.2 测试数据集

测试使用人造数据和真实数据

• MIW、SIW和QW使用SNAP数据集

  • Enron Dataset

  • Amazon dataset

  • Youtube dataset

  • LiveJournal dataset

• CW使用LFR-Benchmark generator生成的人造数据

本测试用到的数据集规模

1.3 服务配置

• HugeGraph版本：0.5.6，RestServer和Gremlin Server和backends都在同一台服务器上

  • RocksDB版本：rocksdbjni-5.8.6

• Titan版本：0.5.4, 使用thrift+Cassandra模式

  • Cassandra版本：cassandra-3.10，commit-log 和 data 共用SSD

• Neo4j版本：2.0.1

graphdb-benchmark适配的Titan版本为0.5.4

2 测试结果

2.1 Batch插入性能

说明

• 表头"（）“中数据是数据规模，以边为单位
• 表中数据是批量插入的时间，单位是s
• 例如，HugeGraph使用RocksDB插入amazon0601数据集的300w条边，花费5.711s

结论

• 批量插入性能 HugeGraph(RocksDB) > Neo4j > Titan(thrift+Cassandra)

2.2 遍历性能

2.2.1 术语说明

• FN(Find Neighbor), 遍历所有vertex, 根据vertex查邻接edge, 通过edge和vertex查other vertex
• FA(Find Adjacent), 遍历所有edge，根据edge获得source vertex和target vertex

2.2.2 FN性能

说明

• 表头”（）“中数据是数据规模，以顶点为单位
• 表中数据是遍历顶点花费的时间，单位是s
• 例如，HugeGraph使用RocksDB后端遍历amazon0601的所有顶点，并查找邻接边和另一顶点，总共耗时45.118s

2.2.3 FA性能

说明

• 表头”（）“中数据是数据规模，以边为单位
• 表中数据是遍历边花费的时间，单位是s
• 例如，HugeGraph使用RocksDB后端遍历amazon0601的所有边，并查询每条边的两个顶点，总共耗时10.764s

结论

• 遍历性能 Neo4j > HugeGraph(RocksDB) > Titan(thrift+Cassandra)

2.3 HugeGraph-图常用分析方法性能

术语说明

• FS(Find Shortest Path), 寻找最短路径
• K-neighbor，从起始vertex出发，通过K跳边能够到达的所有顶点, 包括1, 2, 3…(K-1), K跳边可达vertex
• K-out, 从起始vertex出发，恰好经过K跳out边能够到达的顶点

FS性能

说明

• 表头”（）“中数据是数据规模，以边为单位
• 表中数据是找到从第一个顶点出发到达随机选择的100个顶点的最短路径的时间，单位是s
• 例如，HugeGraph使用RocksDB后端在图amazon0601中查找第一个顶点到100个随机顶点的最短路径，总共耗时0.103s

结论

• 在数据规模小或者顶点关联关系少的场景下，HugeGraph性能优于Neo4j和Titan
• 随着数据规模增大且顶点的关联度增高，HugeGraph与Neo4j性能趋近，都远高于Titan

K-neighbor性能

说明

• HugeGraph-Server的JVM内存设置为32GB，数据量过大时会出现OOM

K-out性能

说明

• HugeGraph-Server的JVM内存设置为32GB，数据量过大时会出现OOM

结论

• FS场景，HugeGraph性能优于Neo4j和Titan
• K-neighbor和K-out场景，HugeGraph能够实现在5度范围内秒级返回结果

2.4 图综合性能测试-CW

说明

• “规模"以顶点为单位
• 表中数据是社区发现完成需要的时间，单位是s，例如HugeGraph使用RocksDB后端在规模10000的数据集，社区聚合不再变化，需要耗时744.780s
• CW测试是CRUD的综合评估
• 该测试中HugeGraph跟Titan一样，没有通过client，直接对core操作

结论

• 社区聚类算法性能 Neo4j > HugeGraph > Titan

2 - HugeGraph-API Performance

HugeGraph API性能测试主要测试HugeGraph-Server对RESTful API请求的并发处理能力，包括：

• 顶点/边的单条插入
• 顶点/边的批量插入
• 顶点/边的查询

HugeGraph的每个发布版本的RESTful API的性能测试情况可以参考：

• v0.5.6 stand-alone
• v0.5.6 cluster
• v0.4.4
• v0.2

之前的版本只提供HugeGraph所支持的后端种类中性能最好的API性能测试，从0.5.6版本开始，分别提供了单机和集群的性能情况

2.1 - v0.5.6 Stand-alone(RocksDB)

1 测试环境

被压机器信息

• 起压力机器信息：与被压机器同配置
• 测试工具：apache-Jmeter-2.5.1

注：起压机器和被压机器在同一机房

2 测试说明

2.1 名词定义（时间的单位均为ms）

• Samples – 本次场景中一共完成了多少个线程
• Average – 平均响应时间
• Median – 统计意义上面的响应时间的中值
• 90% Line – 所有线程中90%的线程的响应时间都小于xx
• Min – 最小响应时间
• Max – 最大响应时间
• Error – 出错率
• Throughput – 吞吐量
• KB/sec – 以流量做衡量的吞吐量

2.2 底层存储

后端存储使用RocksDB，HugeGraph与RocksDB都在同一机器上启动，server相关的配置文件除主机和端口有修改外，其余均保持默认。

3 性能结果总结

1. HugeGraph单条插入顶点和边的速度在每秒1w左右
2. 顶点和边的批量插入速度远大于单条插入速度
3. 按id查询顶点和边的并发度可达到13000以上，且请求的平均延时小于50ms

4 测试结果及分析

4.1 batch插入

4.1.1 压力上限测试

测试方法

不断提升并发量，测试server仍能正常提供服务的压力上限

压力参数

持续时间：5min

顶点的最大插入速度：

####### 结论：

• 并发2200，顶点的吞吐量是2026.8，每秒可处理的数据：2026.8*200=405360/s

边的最大插入速度

####### 结论：

• 并发900，边的吞吐量是776.9，每秒可处理的数据：776.9*500=388450/s

4.2 single插入

4.2.1 压力上限测试

测试方法

不断提升并发量，测试server仍能正常提供服务的压力上限

压力参数

• 持续时间：5min
• 服务异常标志：错误率大于0.00%

顶点的单条插入

####### 结论：

• 并发11500，吞吐量为10730，顶点的单条插入并发能力为11500

边的单条插入

####### 结论：

• 并发9000，吞吐量是8418，边的单条插入并发能力为9000

4.3 按id查询

4.3.1 压力上限测试

测试方法

不断提升并发量，测试server仍能正常提供服务的压力上限

压力参数

• 持续时间：5min
• 服务异常标志：错误率大于0.00%

顶点的按id查询

####### 结论：

• 并发14000，吞吐量是12663，顶点的按id查询的并发能力为14000，平均延时为44ms

边的按id查询

####### 结论：

• 并发13000，吞吐量是12225，边的按id查询的并发能力为13000，平均延时为12ms

2.2 - v0.5.6 Cluster(Cassandra)

1 测试环境

被压机器信息

• 起压力机器信息：与被压机器同配置
• 测试工具：apache-Jmeter-2.5.1

注：起压机器和被压机器在同一机房

2 测试说明

2.1 名词定义（时间的单位均为ms）

• Samples – 本次场景中一共完成了多少个线程
• Average – 平均响应时间
• Median – 统计意义上面的响应时间的中值
• 90% Line – 所有线程中90%的线程的响应时间都小于xx
• Min – 最小响应时间
• Max – 最大响应时间
• Error – 出错率
• Throughput – 吞吐量
• KB/sec – 以流量做衡量的吞吐量

2.2 底层存储

后端存储使用15节点Cassandra集群，HugeGraph与Cassandra集群位于不同的服务器，server相关的配置文件除主机和端口有修改外，其余均保持默认。

3 性能结果总结

1. HugeGraph单条插入顶点和边的速度分别为9000和4500
2. 顶点和边的批量插入速度分别为5w/s和15w/s，远大于单条插入速度
3. 按id查询顶点和边的并发度可达到12000以上，且请求的平均延时小于70ms

4 测试结果及分析

4.1 batch插入

4.1.1 压力上限测试

测试方法

不断提升并发量，测试server仍能正常提供服务的压力上限

压力参数

持续时间：5min

顶点的最大插入速度：

####### 结论：

• 并发3500，顶点的吞吐量是261，每秒可处理的数据：261*200=52200/s

边的最大插入速度

####### 结论：

• 并发1000，边的吞吐量是323，每秒可处理的数据：323*500=161500/s

4.2 single插入

4.2.1 压力上限测试

测试方法

不断提升并发量，测试server仍能正常提供服务的压力上限

压力参数

• 持续时间：5min
• 服务异常标志：错误率大于0.00%

顶点的单条插入

####### 结论：

• 并发9000，吞吐量为8400，顶点的单条插入并发能力为9000

边的单条插入

####### 结论：

• 并发4500，吞吐量是4160，边的单条插入并发能力为4500

4.3 按id查询

4.3.1 压力上限测试

测试方法

不断提升并发量，测试server仍能正常提供服务的压力上限

压力参数

• 持续时间：5min
• 服务异常标志：错误率大于0.00%

顶点的按id查询

####### 结论：

• 并发14500，吞吐量是13576，顶点的按id查询的并发能力为14500，平均延时为11ms

边的按id查询

####### 结论：

• 并发12000，吞吐量是10688，边的按id查询的并发能力为12000，平均延时为63ms

2.3 - v0.4.4

1 测试环境

被压机器信息

• 起压力机器信息：与编号 1 机器同配置
• 测试工具：apache-Jmeter-2.5.1

注：起压机器和被压机器在同一机房

2 测试说明

2.1 名词定义（时间的单位均为ms）

• Samples – 本次场景中一共完成了多少个线程
• Average – 平均响应时间
• Median – 统计意义上面的响应时间的中值
• 90% Line – 所有线程中90%的线程的响应时间都小于xx
• Min – 最小响应时间
• Max – 最大响应时间
• Error – 出错率
• Throughput – 吞吐量
• KB/sec – 以流量做衡量的吞吐量

2.2 底层存储

后端存储使用RocksDB，HugeGraph与RocksDB都在同一机器上启动，server相关的配置文件除主机和端口有修改外，其余均保持默认。

3 性能结果总结

1. HugeGraph每秒能够处理的请求数目上限是7000
2. 批量插入速度远大于单条插入，在服务器上测试结果达到22w edges/s，37w vertices/s
3. 后端是RocksDB，增大CPU数目和内存大小可以增大批量插入的性能。CPU和内存扩大一倍，性能增加45%-60%
4. 批量插入场景，使用SSD替代HDD，性能提升较小，只有3%-5%

4 测试结果及分析

4.1 batch插入

4.1.1 压力上限测试

测试方法

不断提升并发量，测试server仍能正常提供服务的压力上限

压力参数

持续时间：5min

顶点和边的最大插入速度（高性能服务器，使用SSD存储RocksDB数据）：

结论：

• 并发1000，边的吞吐量是是451，每秒可处理的数据：451*500条=225500/s
• 并发2000，顶点的吞吐量是1842.4，每秒可处理的数据：1842.4*200=368480/s

1. CPU和内存对插入性能的影响（服务器都使用HDD存储RocksDB数据，批量插入）

结论：

• 同样使用HDD硬盘，CPU和内存增加了1倍
• 边：吞吐量从268提升至426，性能提升了约60%
• 顶点：吞吐量从1263.8提升至1842.4，性能提升了约45%

2. SSD和HDD对插入性能的影响（高性能服务器，批量插入）

结论：

• 边：使用SSD吞吐量451.7,使用HDD吞吐量426.6，性能提升5%
• 顶点：使用SSD吞吐量1842.4，使用HDD吞吐量1794，性能提升约3%

3. 不同并发线程数对插入性能的影响（普通服务器，使用HDD存储RocksDB数据）

结论：

• 顶点：1000并发，响应时间7ms和1500并发响应时间1028ms差距悬殊，且吞吐量一直保持在1300左右，因此拐点数据应该在1300 ，且并发1300时，响应时间已达到22ms，在可控范围内，相比HugeGraph 0.2（1000并发：平均响应时间8959ms），处理能力出现质的飞跃；
• 边：从1000并发到2000并发，处理时间过长，超过3s，且吞吐量几乎在270左右浮动，因此继续增大并发线程数吞吐量不会再大幅增长，270 是一个拐点，跟HugeGraph 0.2版本（1000并发：平均响应时间31849ms）相比较，处理能力提升非常明显；

4.2 single插入

4.2.1 压力上限测试

测试方法

不断提升并发量，测试server仍能正常提供服务的压力上限

压力参数

• 持续时间：5min
• 服务异常标志：错误率大于0.00%

结论：

• 顶点：
  • 4000并发：正常，无错误率，平均耗时小于1ms， 6000并发无错误，平均耗时5ms，在可接受范围内；
  • 8000并发：存在0.01%的错误，已经无法处理，出现connection timeout错误，顶峰应该在7000左右
• 边：
  • 4000并发：响应时间1ms，6000并发无任何异常，平均响应时间8ms，主要差异在于 IO network recv和send以及CPU）；
  • 8000并发：存在0.01%的错误率，平均耗15ms，拐点应该在7000左右，跟顶点结果匹配；

2.4 - v0.2

1 测试环境

1.1 软硬件信息

起压和被压机器配置相同，基本参数如下：

测试工具：apache-Jmeter-2.5.1

1.2 服务配置

• HugeGraph版本：0.2
• 后端存储：使用服务内嵌的cassandra-3.10，单点部署；
• 后端配置修改：修改了cassandra.yaml文件中的以下两个属性，其余选项均保持默认

  batch_size_warn_threshold_in_kb: 1000
  batch_size_fail_threshold_in_kb: 1000

• HugeGraphServer 与 HugeGremlinServer 与cassandra都在同一机器上启动，server 相关的配置文件除主机和端口有修改外，其余均保持默认。

1.3 名词解释

• Samples – 本次场景中一共完成了多少个线程
• Average – 平均响应时间
• Median – 统计意义上面的响应时间的中值
• 90% Line – 所有线程中90%的线程的响应时间都小于xx
• Min – 最小响应时间
• Max – 最大响应时间
• Error – 出错率
• Troughput – 吞吐量Â
• KB/sec – 以流量做衡量的吞吐量

注：时间的单位均为ms

2 测试结果

2.1 schema

结论：schema的接口，在1000并发持续5分钟的压力下，平均响应时间1-2ms，无压力

2.2 single 插入

2.2.1 插入速率测试

压力参数

测试方法：固定并发量，测试server和后端的处理速率

• 并发量：1000
• 持续时间：5min

性能指标

结论

• 顶点：平均响应时间1ms，每个请求插入一条数据，平均每秒处理920个请求，则每秒平均总共处理的数据为1*920约等于920条数据；
• 边：平均响应时间1ms，每个请求插入一条数据，平均每秒处理920个请求，则每秒平均总共处理的数据为1*920约等于920条数据；

2.2.2 压力上限测试

测试方法：不断提升并发量，测试server仍能正常提供服务的压力上限

压力参数

• 持续时间：5min
• 服务异常标志：错误率大于0.00%

性能指标

结论

• 顶点：
  • 4000并发：正常，无错误率，平均耗时13ms；
  • 5000并发：每秒处理5000个数据的插入，就会存在0.06%的错误，应该已经处理不了了，顶峰应该在4000
• 边：
  • 1000并发：响应时间2ms，跟2000并发的响应时间相差较多，主要是 IO network rec和send以及CPU几乎增加了一倍）；
  • 2000并发：每秒处理2000个数据的插入，平均耗时953ms，平均每秒处理1750个请求；
  • 3000并发：每秒处理3000个数据的插入，平均耗时2258ms，平均每秒处理1810个请求；
  • 4000并发：每秒处理4000个数据的插入，平均每秒处理1812个请求；

2.3 batch 插入

2.3.1 插入速率测试

压力参数

测试方法：固定并发量，测试server和后端的处理速率

• 并发量：1000
• 持续时间：5min

性能指标

结论

• 顶点：平均响应时间为8959ms，处理时间过长。每个请求插入199条数据，平均每秒处理103个请求，则每秒平均总共处理的数据为199*131约等于2w条数据；
• 边：平均响应时间31849ms，处理时间过长。每个请求插入499个数据，平均每秒处理28个请求，则每秒平均总共处理的数据为28*499约等于13900条数据；

3 - HugeGraph-Loader Performance

使用场景

当要批量插入的图数据（包括顶点和边）条数为billion级别及以下，或者总数据量小于TB时，可以采用HugeGraph-Loader工具持续、高速导入图数据

性能

测试均采用网址数据的边数据

RocksDB单机性能

• 关闭label index，22.8w edges/s
• 开启label index，15.3w edges/s

Cassandra集群性能

• 默认开启label index，6.3w edges/s

4 - HugeGraph 0.4.4 Benchmark

1 测试环境

1.1 硬件信息

1.2 软件信息

1.2.1 测试用例

测试使用graphdb-benchmark，一个图数据库测试集。该测试集主要包含4类测试：

• Massive Insertion，批量插入顶点和边，一定数量的顶点或边一次性提交

• Single Insertion，单条插入，每个顶点或者每条边立即提交

• Query，主要是图数据库的基本查询操作：

  • Find Neighbors，查询所有顶点的邻居
  • Find Adjacent Nodes，查询所有边的邻接顶点
  • Find Shortest Path，查询第一个顶点到100个随机顶点的最短路径

• Clustering，基于Louvain Method的社区发现算法

1.2.2 测试数据集

测试使用人造数据和真实数据

• MIW、SIW和QW使用SNAP数据集

  • Enron Dataset

  • Amazon dataset

  • Youtube dataset

  • LiveJournal dataset

• CW使用LFR-Benchmark generator生成的人造数据

本测试用到的数据集规模

1.3 服务配置

• HugeGraph版本：0.4.4，RestServer和Gremlin Server和backends都在同一台服务器上
• Cassandra版本：cassandra-3.10，commit-log 和data共用SSD
• RocksDB版本：rocksdbjni-5.8.6
• Titan版本：0.5.4, 使用thrift+Cassandra模式

graphdb-benchmark适配的Titan版本为0.5.4

2 测试结果

2.1 Batch插入性能

说明

• 表头"（）“中数据是数据规模，以边为单位
• 表中数据是批量插入的时间，单位是s
• 例如，HugeGraph使用RocksDB插入amazon0601数据集的300w条边，花费14.076s，速度约为21w edges/s

结论

• RocksDB和Memory后端插入性能优于Cassandra
• HugeGraph和Titan同样使用Cassandra作为后端的情况下，插入性能接近

2.2 遍历性能

2.2.1 术语说明

• FN(Find Neighbor), 遍历所有vertex, 根据vertex查邻接edge, 通过edge和vertex查other vertex
• FA(Find Adjacent), 遍历所有edge，根据edge获得source vertex和target vertex

2.2.2 FN性能

说明

• 表头”（）“中数据是数据规模，以顶点为单位
• 表中数据是遍历顶点花费的时间，单位是s
• 例如，HugeGraph使用RocksDB后端遍历amazon0601的所有顶点，并查找邻接边和另一顶点，总共耗时65.852s

2.2.3 FA性能

说明

• 表头”（）“中数据是数据规模，以边为单位
• 表中数据是遍历边花费的时间，单位是s
• 例如，HugeGraph使用RocksDB后端遍历amazon0601的所有边，并查询每条边的两个顶点，总共耗时64.526s

结论

• HugeGraph RocksDB > Titan thrift+Cassandra > HugeGraph Cassandra > HugeGraph Memory

2.3 HugeGraph-图常用分析方法性能

术语说明

• FS(Find Shortest Path), 寻找最短路径
• K-neighbor，从起始vertex出发，通过K跳边能够到达的所有顶点, 包括1, 2, 3…(K-1), K跳边可达vertex
• K-out, 从起始vertex出发，恰好经过K跳out边能够到达的顶点

FS性能

说明

• 表头”（）“中数据是数据规模，以边为单位
• 表中数据是找到从第一个顶点出发到达随机选择的100个顶点的最短路径的时间，单位是s
• 例如，HugeGraph使用RocksDB查找第一个顶点到100个随机顶点的最短路径，总共耗时2.059s

结论

• 在数据规模小或者顶点关联关系少的场景下，Titan最短路径性能优于HugeGraph
• 随着数据规模增大且顶点的关联度增高，HugeGraph最短路径性能优于Titan

K-neighbor性能

说明

• HugeGraph-Server的JVM内存设置为32GB，数据量过大时会出现OOM

K-out性能

说明

• HugeGraph-Server的JVM内存设置为32GB，数据量过大时会出现OOM

结论

• FS场景，HugeGraph性能优于Titan
• K-neighbor和K-out场景，HugeGraph能够实现在5度范围内秒级返回结果

2.4 图综合性能测试-CW

说明

• “规模"以顶点为单位
• 表中数据是社区发现完成需要的时间，单位是s，例如HugeGraph使用RocksDB后端在规模10000的数据集，社区聚合不再变化，需要耗时763.869s
• “*“表示超过10000s未完成
• CW测试是CRUD的综合评估
• 后三者分别是HugeGraph的不同后端，该测试中HugeGraph跟Titan一样，没有通过client，直接对core操作

结论

• HugeGraph在使用Cassandra后端时，性能略优于Titan，随着数据规模的增大，优势越来越明显，数据规模20000时，比Titan快30%
• HugeGraph在使用RocksDB后端时，性能远高于Titan和HugeGraph的Cassandra后端，分别比两者快了6倍和4倍