- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
场景:在局域网内,需要将多个机器网卡上抓到的数据包同步到一个机器上。 原有方案:tcpdump -w 写入文件,然后定时调用 rsync 进行同步。 改造方案:使用 Go 重写这个抓包逻辑及同步逻辑,直接将抓到的包通过网络发送至服务端,由服务端写入,这样就减少了一次落盘的操作.
构造一个 pcap 文件很简单,需要写入一个 pcap文件头,后面每一条数据增加一个元数据进行描述。 使用 pcapgo 即可实现这个功能,p.buffer[:ci.CaptureLength] 为抓包的数据.
ci := gopacket.CaptureInfo{
CaptureLength: int(n),
Length: int(n),
Timestamp: time.Now(),
}
if ci.CaptureLength > len(p.buffer) {
ci.CaptureLength = len(p.buffer)
}
w.WritePacket(ci, p.buffer[:ci.CaptureLength])
为了通过区分是哪个机器过来的数据包需要增加一个 Id,算上元数据和原始数据包,表达结构如下 。
// from github.com/google/gopacket
type CaptureInfo struct {
// Timestamp is the time the packet was captured, if that is known.
Timestamp time.Time `json:"ts" msgpack:"ts"`
// CaptureLength is the total number of bytes read off of the wire.
CaptureLength int `json:"cap_len" msgpack:"cap_len"`
// Length is the size of the original packet. Should always be >=
// CaptureLength.
Length int `json:"len" msgpack:"len"`
// InterfaceIndex
InterfaceIndex int `json:"iface_idx" msgpack:"iface_idx"`
}
type CapturePacket struct {
CaptureInfo
Id uint32 `json:"id" msgpack:"id"`
Data []byte `json:"data" msgpack:"data"`
}
有一个细节待敲定,抓到的包使用什么结构发送至服务端?json/msgpack/自定义格式?
json/msgpack 都有对应的规范,通用性强,不容易出 BUG,性能会差一点。 自定义格式相比 json/msgpack 而言,可以去掉不必要的字段,连 key 都可以不用在序列化中出现,并且可以通过一些优化减少内存的分配,缓解gc压力.
自定义二进制协议优化思路如下 。
sync.Pool 的优化点有两个 。
func acquirePacketBuf(n int) ([]byte, func()) {
var (
buf []byte
putfn func()
)
if n <= CapturePacketMetaLen+128 {
smallBuf := smallBufPool.Get().(*[CapturePacketMetaLen + 128]byte)
buf = smallBuf[:0]
putfn = func() { smallBufPool.Put(smallBuf) }
} else if n <= CapturePacketMetaLen+1024 {
midBuf := midBufPool.Get().(*[CapturePacketMetaLen + 1024]byte)
buf = midBuf[:0]
putfn = func() { midBufPool.Put(midBuf) }
} else if n <= CapturePacketMetaLen+8192 {
largeBuf := largeBufPool.Get().(*[CapturePacketMetaLen + 8192]byte)
buf = largeBuf[:0]
putfn = func() { largeBufPool.Put(largeBuf) }
} else {
xlargeBuf := xlargeBufPool.Get().(*[CapturePacketMetaLen + 65536]byte)
buf = xlargeBuf[:0]
putfn = func() { xlargeBufPool.Put(xlargeBuf) }
}
return buf, putfn
}
func (binaryPack) EncodeTo(p *CapturePacket, w io.Writer) (int, error) {
buf := metaBufPool.Get().(*[CapturePacketMetaLen]byte)
defer metaBufPool.Put(buf)
binary.BigEndian.PutUint64(buf[0:], uint64(p.Timestamp.UnixMicro()))
...
return nm + nd, err
}
方法 | 原始数据长度 (字节) | 编码后数据长度 (字节) | 变化字节数 (字节) |
---|---|---|---|
Binary Pack | 72 | 94 | +22 |
Binary Pack | 1024 | 1046 | +22 |
Binary Pack | 16384 | 16406 | +22 |
MsgPack | 72 | 150 | +78 |
MsgPack | 1024 | 1103 | +79 |
MsgPack | 16384 | 16463 | +79 |
Json Pack | 72 | 191 | +119 |
Json Pack | 1024 | 1467 | +443 |
Json Pack | 16384 | 21949 | +5565 |
Json Compress Pack | 72 | 195 | +123 |
Json Compress Pack | 1024 | 1114 | +90 |
Json Compress Pack | 16384 | 15504 | -120 |
Binary Pack:
MsgPack:
Json Pack:
Json Compress Pack:
通过这个表格,你可以更直观地看到不同数据打包方法在不同数据量下的表现。希望这对你有帮助! 。
可以看到使用 buffer 进行复用提升比较明显,主要还是减少内存分配带来的提升.
BenchmarkJsonPack/encode#72-20 17315143 647.1 ns/op 320 B/op 3 allocs/op
BenchmarkJsonPack/encode#1024-20 4616841 2835 ns/op 1666 B/op 3 allocs/op
BenchmarkJsonPack/encode#16384-20 365313 34289 ns/op 24754 B/op 3 allocs/op
BenchmarkJsonPack/encode_with_buf#72-20 24820188 447.4 ns/op 128 B/op 2 allocs/op
BenchmarkJsonPack/encode_with_buf#1024-20 13139395 910.6 ns/op 128 B/op 2 allocs/op
BenchmarkJsonPack/encode_with_buf#16384-20 1414260 8472 ns/op 128 B/op 2 allocs/op
BenchmarkJsonPack/decode#72-20 8699952 1364 ns/op 304 B/op 8 allocs/op
BenchmarkJsonPack/decode#1024-20 2103712 5605 ns/op 1384 B/op 8 allocs/op
BenchmarkJsonPack/decode#16384-20 159140 73101 ns/op 18664 B/op 8 allocs/op
同样看到使用 buffer 进行复用的提升,和 json 的分水岭大概在 1024 字节左右,超过这个大小 msgpack 速度快很多,并且在解析的时候内存占用不会随数据进行增长.
BenchmarkMsgPack/encode#72-20 10466427 1199 ns/op 688 B/op 8 allocs/op
BenchmarkMsgPack/encode#1024-20 6599528 2132 ns/op 1585 B/op 8 allocs/op
BenchmarkMsgPack/encode#16384-20 1478127 8806 ns/op 18879 B/op 8 allocs/op
BenchmarkMsgPack/encode_with_buf#72-20 26677507 388.2 ns/op 192 B/op 4 allocs/op
BenchmarkMsgPack/encode_with_buf#1024-20 31426809 400.2 ns/op 192 B/op 4 allocs/op
BenchmarkMsgPack/encode_with_buf#16384-20 22588560 494.5 ns/op 192 B/op 4 allocs/op
BenchmarkMsgPack/decode#72-20 19894509 654.2 ns/op 280 B/op 10 allocs/op
BenchmarkMsgPack/decode#1024-20 18211321 664.0 ns/op 280 B/op 10 allocs/op
BenchmarkMsgPack/decode#16384-20 13755824 769.1 ns/op 280 B/op 10 allocs/op
在内网的情况下,带宽不是问题,这个压测结果直接被 Pass 。
BenchmarkJsonCompressPack/encode#72-20 19934 709224 ns/op 1208429 B/op 26 allocs/op
BenchmarkJsonCompressPack/encode#1024-20 17577 766349 ns/op 1212782 B/op 26 allocs/op
BenchmarkJsonCompressPack/encode#16384-20 11757 860371 ns/op 1253975 B/op 25 allocs/op
BenchmarkJsonCompressPack/decode#72-20 490164 28972 ns/op 42048 B/op 15 allocs/op
BenchmarkJsonCompressPack/decode#1024-20 187113 71612 ns/op 47640 B/op 23 allocs/op
BenchmarkJsonCompressPack/decode#16384-20 35790 346580 ns/op 173352 B/op 30 allocs/op
对于序列化和反序列化在复用内存后,速度的提升非常明显,在同步的操作下,能做到 0 字节分配。异步场景下,使用 sync.Pool 内存固定字节分配(两个返回值在堆上分配) 。
BenchmarkBinaryPack/encode#72-20 72744334 187.1 ns/op 144 B/op 2 allocs/op
BenchmarkBinaryPack/encode#1024-20 17048832 660.6 ns/op 1200 B/op 2 allocs/op
BenchmarkBinaryPack/encode#16384-20 2085050 6280 ns/op 18495 B/op 2 allocs/op
BenchmarkBinaryPack/encode_with_pool#72-20 34700313 109.2 ns/op 64 B/op 2 allocs/op
BenchmarkBinaryPack/encode_with_pool#1024-20 39370662 101.1 ns/op 64 B/op 2 allocs/op
BenchmarkBinaryPack/encode_with_pool#16384-20 18445262 177.2 ns/op 64 B/op 2 allocs/op
BenchmarkBinaryPack/encode_to#72-20 705428736 16.96 ns/op 0 B/op 0 allocs/op
BenchmarkBinaryPack/encode_to#1024-20 575312358 20.78 ns/op 0 B/op 0 allocs/op
BenchmarkBinaryPack/encode_to#16384-20 100000000 113.4 ns/op 0 B/op 0 allocs/op
BenchmarkBinaryPack/decode_meta#72-20 1000000000 2.887 ns/op 0 B/op 0 allocs/op
BenchmarkBinaryPack/decode_meta#1024-20 1000000000 2.882 ns/op 0 B/op 0 allocs/op
BenchmarkBinaryPack/decode_meta#16384-20 1000000000 2.876 ns/op 0 B/op 0 allocs/op
BenchmarkBinaryPack/decode#72-20 100000000 85.63 ns/op 80 B/op 1 allocs/op
BenchmarkBinaryPack/decode#1024-20 7252350 445.4 ns/op 1024 B/op 1 allocs/op
BenchmarkBinaryPack/decode#16384-20 554329 5499 ns/op 16384 B/op 1 allocs/op
BenchmarkBinaryPack/decode_with_pool#72-20 109352595 33.97 ns/op 16 B/op 1 allocs/op
BenchmarkBinaryPack/decode_with_pool#1024-20 85589674 36.27 ns/op 16 B/op 1 allocs/op
BenchmarkBinaryPack/decode_with_pool#16384-20 26163607 140.4 ns/op 16 B/op 1 allocs/op
Binary Pack: - encode_to:性能最优,几乎没有内存分配,适用于高性能要求的场景。 - encode_with_pool:使用内存池优化,显著减少了时间和内存开销,适用于大多数场景。 - encode:标准方法,时间和内存开销较高。 MsgPack: - encode_with_buf:使用预分配的缓冲区,显著减少了时间和内存开销,适用于大多数场景。 - encode:标准方法,时间和内存开销较高。 - decode:解码性能一般,内存开销较高。 Json Pack: - encode_with_buf:使用预分配的缓冲区,显著减少了时间和内存开销,适用于大多数场景。 - encode:标准方法,时间和内存开销较高。 - decode:解码性能较差,内存开销较高。 Json Compress Pack: - encode:标准方法,时间和内存开销非常高,不推荐用于高性能要求的场景。 - decode:解码性能较差,内存开销较高.
在内网的环境进行传输,一般网络带宽不会成为瓶颈,所以可以不用考虑数据压缩,上面结果也看到压缩非常占用资源; 如果对数据内容不关心且数据量非常多的情况下(比如传输 pcap 包),那么使用自定义协议可能更合适一些,固定长度的元数据解析起来优化空间巨大,二进制解析比 json/msgpack 快内存分配也非常少.
最后此篇关于优化Go语言数据打包:性能基准测试与分析的文章就讲到这里了,如果你想了解更多关于优化Go语言数据打包:性能基准测试与分析的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我在使用 nuget 打包新包时遇到问题,因为当我通过命令行指定版本时,它会将它应用于包而不是依赖项。即 NuGet.exe pack myproject.csproj -Version 3.0.4.
考虑这个简短的例子: $a = pack("d",255); print length($a)."\n"; # Prints 8 $aa = pack("ddddd", 255,123,0,45,12
我有一个我想要的无符号整数数组(32 位) pack 成二进制流: my @n = (4,8,15,16,23,42); my $foo = join('', map(pack('I', $_), @
在我的工作中,我们必须在各种环境中部署应用程序。这是一个标准的 WAR 文件,需要一些配置,部署在 Tomcat 6 上。 有没有什么方法可以使用 Tomcat 创建一个“部署包”,以便您只需提取它并
我正在编写一个简单的数据包序列化程序,但我很难为我的数据包创建 header 。我正在创建一个缓冲区,然后尝试将前两项加载到缓冲区中。我运行 memcopy 但缓冲区中实际上没有任何内容,然后当我尝试
有人可以解释为什么当你有一个普通的小部件时,一行代码 A 可以工作 Entry(root, width=10).pack(side=LEFT,anchor=W) 但是当你给它命名或附加命令时,代码 A
我正在尝试使用this tutorial构建Python包。这是文件夹结构: testpackage\ testpackage\ __init__.py
我有 JFrame 和 GridBagLayout。用户可以调整此窗口的大小。此外,他还可以执行一些更改窗口大小的编辑操作。我使用 pack(); repaint(); 现在在这样的操作之后。但是,实
我有一个现实世界的问题,我认为需要某种优化,而不是对我关心的数据数组进行简单排序。我将在下面概述问题: 我有一个由不同设备组成的数据集,每个设备都有属性 A 和 B。A 和 B 彼此不依赖,但是,我想
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持,但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开,visit the
我必须将旧的“加密”数据从旧系统转换为适当的加密算法。我有这段代码: function unpackString($s,$l){ $tmp=unpack('c'.$l,$s);
我有两个发电机。第一个生成器有时需要调用第二个生成器并返回它从那里获得的值: def a(): for _b in b(): yield _b def b(): yie
首先:对不起,我知道有很多关于相对导入的问题,但我只是没有找到解决方案。如果可能的话,我想使用以下目录布局: myClass/ __init__.py test/ de
1 ambari + bigtop 构建大数据基础平台 1.1 参考: 1.2 参考 amabri bigtop 打包部署
所以 SimpleInjector 现在有一个包装 nuget,您可以使用它来隔离根组合的不同方面。 假设我在一个库中有一个可配置的组合根,它被应用程序中的多个项目重用。例如,在 Azure 解决方案
我想以易于分发的形式打包 Groovy CLI 应用程序,类似于 Java 对 JAR 所做的。我一直无法找到任何似乎能够做到这一点的东西。我发现了一些类似 this 的东西用于一次性脚本,但不能编译
目前 ZMI 管理“打包数据库”的功能有点粗糙。 1) 是否有可能为 Web UI 提供某种进度指示器?例如。一个告诉你还剩多少分钟/小时,至少给出某种估计 2) ZODB 打包如何影响站点的响应性?
我有一个看起来像这样的结构: struct vdata { static_assert(sizeof(uint8_t *) == 8L, "size of pointer must be 8");
我已经尝试打包/发布我的 Azure 项目有一段时间了(但没有成功)。我尝试过以下方法: 右键单击 -> 从 Visual Studio 打包/发布 (OutOfMemoryException) CS
我创建了一个 JavaScript 库,并将其打包为以下选定的选项:Shrink Variables和Base62 Encoded在这个网址:http://dean.edwards.name/pack
我是一名优秀的程序员,十分优秀!