AWS-用于在 AWS 上进行构建的工具

Cat性能优化

消息树 -> 实施分析 -> 内存报表

问题

CPU密集型任务

GC频繁

报表分析器

appId + ip 进行哈希

数据和线程绑定，无锁绑定

BIO -> NIO 流量不均导致部分队列堆积

加线程 -> 上下文切换 每秒几百万次

解决方案：

1. 队列和线程解耦

   NIO模型：selector

   1. 队列数据 notify selector

   2. 充分利用线程池

      合并线程池（CPU个数）

   3. 合并selector，实现优先级调度

CPU 90% -> 70%

客户端计算

边缘计算

计算逻辑放在客户端：客户端聚合

1. 不变的逻辑
2. CPU密集型任务

Transaction计算

遍历messagetree，读取数据 -> 客户端合并messagetree，然后发送到服务端

客户端双队列模型

1. messagetree
2. 统计指标队列（优先发送）

小结

1. 客户端有足够上下文信息，类似计算可放在客户端

Report双缓冲

Cat当前小时报表->内存

其他报表 持久化

数据丢失

1. 初始化时map.resize
2. 不可移除资源，无用youngGC
3. young区移到old区，old区不断扩大

解决方法

1. 开始时直接创建要使用的资源，移到old区
2. 每次不创建新的资源，复用缓存资源

小结

1. GC -> young/old区，内存模型

   1. 少分配内存
   2. 是否复用内存

字符串优化

内存中创建大量字符串

字符串损耗

1次 new String
2次 new char[]
1次 字符集解码

对数据流lazy，使用时才反序列化

y

1. string -> byte[]

   BytesWrapper对象有损耗

   4*4对象头
   8字节对齐

2. byte[] -> 重写hashmap

   直接对byte[]的制定位置进行hash，而不是对Objcet继续宁

小结

关注大量使用对象的创建

new string 损耗大

是否可以直接使用byye[]
使用lazy

Object操作的重写，例如hashmap.get(obj) -> get(byte[])

优化思路

1. CPU

   线程模型：上下文、锁竞争

2. GC

   不必要对象创建
   缓存重复创建的对象，复用内存（双缓冲，轮换使用）

调优

使用C++托管内存，JVM不进行管理内存

直接内存（堆外）

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 wshten@gmail.com