Logstash为什么那么慢?—— json序列化

今天跟峡谷金桥聊天,询问起Logstash的性能,金桥提示说Logstash中json的序列化是浪费性能的一方面。于是便有了下面的测试:

第一步,造数据

首先需要造一份数据,数据可以通过logstash的generator来造。

input{
    generator{}
}
output{
    file{
        path => "E:/test.log"
    }
}

生成的数据格式如下:

{"message":"Hello world!","@version":"1","@timestamp":"2016-07-12T13:46:48.821Z","host":"DESKTOP-1GPAD95","sequence":0}
{"message":"Hello world!","@version":"1","@timestamp":"2016-07-12T13:46:48.824Z","host":"DESKTOP-1GPAD95","sequence":1}
{"message":"Hello world!","@version":"1","@timestamp":"2016-07-12T13:46:48.824Z","host":"DESKTOP-1GPAD95","sequence":2}
{"message":"Hello world!","@version":"1","@timestamp":"2016-07-12T13:46:48.825Z","host":"DESKTOP-1GPAD95","sequence":3}
...

第二步,编写测试脚本

测试的思路是,从test.log文件中读取数据。然后计算一定范围内写入的日志数量(靠人工计算啦!)

codec => json 的测试的脚本如下:

input{
    file{
        path => "E:/test.log"
        codec => json
        start_position => "beginning"
    }
}
filter{
    ruby {
        code => "event['tag'] = Time.now"
    }
}
output{
    file{
        path => "E:/json_result3.log"
    }
}

codec => plain 的测试的脚本如下:

input{
    file{
        path => "E:/test.log"
        codec => plain
        start_position => "beginning"
    }
}
filter{
    ruby {
        code => "event['tag'] = Time.now"
    }
}
output{
    file{
        path => "E:/json_result3.log"
    }
}

第三步,计算每10S中产生的日志数量

这里在每条事件中写入了1个时间戳字段,然后打开文件,定位随机定位一个开始的秒数,比如从2016-07-12 22:12:442016-07-12 22:12:54这十秒钟,产生的日志数量就是解析的数量。

为了避免机器差异以及运行环境的差异,所带来的误差,这里每个codec执行了3次,计算得出的数据大致如下:

日志名称

起始时间(行数)

结束时间(行数)

总行数(结束-起始)

json_result1.log

2016-07-12 22:12:44(63)

2016-07-12 22:12:54(34728)

34665

json_result2.log

2016-07-12 22:26:18(517)

2016-07-12 22:26:28(27599)

27082

json_result3.log

2016-07-12 22:27:48(147)

2016-07-12 22:27:58(30352)

30205

plain_result1.log

2016-07-12 22:13:41(300)

2016-07-12 22:13:51(50437)

50137

plain_result2.log

2016-07-12 22:22:32(187)

2016-07-12 22:22:42(53525)

53338

plain_result3.log

2016-07-12 22:24:43(360)

2016-07-12 22:24:53(43580)

43220

测试结果也可以参考下面的图片,更为直观一点:

最后说明

从测试的结果来看,的确plan要比json性能高一些,也就是说logstash在做json序列化的时候浪费了很多的性能。

这就给想要自己写数据采集框架的朋友一点提示——Event对象该如何设计?

PS:由于我选取的数据样本范围都是第一个完整的10秒钟,因此可以看到采集的数据量比较少,平均每秒还不到1w.

这可能受多方条件影响:

  • 1 我是读文件--写文件,对于磁盘IO可能有一定的影响
  • 2 我选取的都是开始的10秒钟数据,可能刚开始数据采集还没有稳定~ 如果有时间的朋友,可以采集个1分钟左右,从最后的10s测试。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ericzli

Jetson TX1上安装Tensorflow Serving遇到的问题总结

本文的目的是分享在TX1上安装Tensorflow Serving时遇到的主要问题,避免重复踩坑。

3723
来自专栏编程

前端性能优化指南——网络篇

网络,在我们开发的页面的访问过程中,是最开始的一个环节,同时,也是一个非常重要的环节。 当我们在提及网络优化的时候,我们都会说些什么呢。 事实上来讲,如果可以话...

2279
来自专栏Linux内核

Linux OOM机制分析

oom_killer(out of memory killer)是Linux内核的一种内存管理机制,在系统可用内存较少的情况下,内核为保证系统还能够继续运行下去...

1.1K7
来自专栏Spark学习技巧

基石 | Flink Checkpoint-轻量级分布式快照

前面两篇,一篇是spark的driver的Checkpoint细节及使用的时候注意事项。一篇是flink的Checkpoint的一些上层解释。本文主要是将fli...

2881
来自专栏Python中文社区

Django 博客教程(三):创建应用和编写数据库模型

專 欄 ❈追梦人物,Python中文社区专栏作者。电子科技大学计算机学院研究生,从事大数据分析研究方向。主要使用 Python 语言进行相关数据的分析,熟练使...

2089
来自专栏云计算教程系列

如何在CentOS 7上使用Skyline检测异常

如果您使用监控系统(如Zabbix或Nagios),那么您就知道监控的工作原理。简而言之,它可以描述如下:监控系统接收各种指标(CPU /内存使用,网络利用率等...

5595
来自专栏黑白安全

绕过CDN获取网站IP地址

基于masscan扫描IP端中开放的80端口,程序自动连接每个IP测试,筛选出符合条件的ip保存到result.txt 后续程序会提供”基于扫描子域名获取IP段...

1123
来自专栏Java技术分享

redis集群原理

 redis是单线程,但是一般的作为缓存使用的话,redis足够了,因为它的读写速度太快了。

3689
来自专栏Java技术分享

redis集群原理

redis是单线程,但是一般的作为缓存使用的话,redis足够了,因为它的读写速度太快了。       官方的一个简单测试:     测试完成了50个并发执行1...

2389
来自专栏沃趣科技

Oracle并行基础

Oracle并行基础 概述 ? Oracle企业版有一项非常厉害的技术:并行查询,也就是说一个语句可以雇佣多个服务器进程(parallel slaves也叫PX...

4707

扫码关注云+社区

领取腾讯云代金券