UMUTech

优化思维【3】消除没必要步骤

故事

四月底给 EOSIO / eos 提了一个优化 MongoDB 插件性能的 PR，被连续感谢好几个 Release。

分析

原先的流程：fc::variant -> JSON string -> BSON，实现起来很简单，因为 JSON 是很常见的，fc::variant 和 BSON 都有到 JSON 的转化，所以实现代码很简单，一行两个函数。

但数据大时，性能问题就暴露了，这个过程先把 fc::variant 对象序列化为 JSON 字符串，然后反序列化到 BSON 对象。两步都是 CPU 密集型操作，由于 nodeos 及其插件暂时对多核支持不好，导致单核跑爆。

两个过程都要用递归实现，调用栈可能很深。调用函数可能有入栈出栈的消耗，有一种优化思路正是用 inline 减少函数的频繁调用。

回归到本质，fc::variant 和 BSON 都是对象，应该直接转化才对。只是实现起来就不是一行能搞定的。先挑简单的方式实现，后期再优化，这是一种挺常规的做法。

UMUTech

SQLite Node.js

选型

mapbox / sqlite3: Asynchronous, non-blocking SQLite3 bindings for Node.js

安装：

1
yarn add sqlite3

常见操作

创建数据库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
const path = require('path')
const sqlite = require('sqlite3')

const dbPath = path.join(__dirname, 'test.db')
const db = new sqlite.Database(dbPath)

const sqls = [`CREATE TABLE test(
  id CHAR(64) NOT NULL PRIMARY KEY CHECK(LENGTH(id) == 64),
  timeStamp INTEGER NOT NULL,
  state INTEGER NOT NULL DEFAULT 0)`
  , 'CREATE INDEX index_id ON txs(id)'
  , 'CREATE INDEX index_timeStamp ON txs(timeStamp)'
  , 'CREATE INDEX index_state ON txs(state)'
]

db.serialize(() => {
  for (let sql of sqls) {
    db.run(sql, (err) => {
      if (err) {
        console.error(err)
      } else {
        console.log('SQL executed.')
      }
    })
  }
})

db.close()

插入数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
const items = [
  { hash: 'D141925E39814FB5256615A1A94EC82B7043D983F68423D8C149A2AE360B623C'
    , ts: 1563273661316, state: 0 }
  , { hash: '2E9F26F5D0A73AE5DAFC8A1C22264725972AA997A22522A906D8CD7E225096ED'
    , ts: 1563273661317, state: 1 }
  , { hash: '0FF5F5F5E96664939D07D94975342D71F824747EFECE1D24FDDBB3B29DD91DCB'
    , ts: 1563273661318, state: 0 }
]

db.serialize(() => {
  const stmt = db.prepare("INSERT INTO test VALUES (?, ?, ?)")
  for (const item of items) {
    stmt.run(item.hash, item.ts, item.state, (err) => {
        if (err) {
          console.error(err)
        } else {
          console.log('INSERT', item.hash)
        }
      })
  }
  stmt.finalize()
})

查询

1
2
3
4
5
6
7
8
9
10
11
db.serialize(() => {
  db.each("SELECT * FROM test WHERE state=0", (err, row) => {
    if (err) {
      console.error('SELECT state=0 error:', err)
    } else {
      // do something here
    }
  }, (err, count) => {
    // do something here
  })
})

更新

1
2
3
4
5
6
7
db.run("UPDATE test SET state=1 WHERE state=0", (err) => {
    if (err) {
      console.error('UPDATE txs error:', err)
    } else {
      console.log('UPDATE state to 1')
    }
  })

参考

http://www.sqlitetutorial.net/sqlite-nodejs/

UMUTech

pm2 运维经验

安装

比较多的文章推荐用 npm 安装，但 UMU 更推荐 yarn。

理由：Visual Studio Code 脑残粉跟随 Microsoft/vscode 使用 yarn。

参考 yarn 安装，其中 Ubuntu 下命令为：

1
2
3
4
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list

sudo apt-get update && sudo apt-get install --no-install-recommends yarn

使用 yarn 安装 pm2：

1
yarn global add pm2

运行

不熟悉 yarn 的话，装完一头雾水，装到哪了？用以下命令显示：

1
yarn global bin

结果参考：

  • macOS：/usr/local/bin
  • Ubuntu：/home/ubuntu/.yarn/bin

启动脚本的命令为：

1
`yarn global bin`/pm2 start my-program.js

安全建议

root 身份能不用则不用。

UMUTech

鸡兔同笼问题的程序解法

定义

“鸡兔同笼问题”是我国古算书《孙子算经》中著名的数学问题，其内容是：

今有雉（鸡）兔同笼，上有三十五头，下有九十四足。问雉兔各几何。

数学描述

设鸡有 x 只，兔有 y 只，则：

1
2
x + y = 35
2x + 4y = 94

解这个方程组得 x = 23, y = 12。

用矩阵表示：

1
2
[1, 1]  *  [x]  =  [35]
[2, 4]     [y]     [94]

Python 代码

1
2
3
4
5
6
>>> import numpy as np
>>> a = np.mat([[1, 1], [2, 4]])
>>> b = np.mat([[35], [94]])
>>> a.I * b
matrix([[23.],
        [12.]])

再来一题三元版本：

有蜘蛛，蜻蜓，蝉三种动物共 18 只，共有腿 118 条，翅膀 20 对，三种动物各几只？

蜘蛛 8 条腿；蜻蜓 6 条腿， 2 对翅膀；蝉 6 条腿，1 对翅膀。

1
2
3
[1, 1, 1]     [x]     [18]
[8, 6, 6]  *  [y]  =  [118]
[0, 2, 1]     [z]     [20]

代码：

1
2
3
4
5
6
7
>>> import numpy as np
>>> a = np.mat([[1, 1, 1], [8, 6, 6], [0, 2, 1]])
>>> b = np.mat([[18], [118], [20]])
>>> a.I * b
matrix([[5.],
        [7.],
        [6.]])
UMUTech

优化思维【2】有符号和无符号的本质区别

做题

以下代码打印什么？

1
2
3
4
5
6
7
auto count = sizeof (int);
if (count > -1) {
  std::cout << "> -1";
}
else {
  std::cout << "<= -1";
}

答案是：<= -1，因为 sizeof (int) 是无符号的，把 auto 改为 int 则结果是 > -1。

本质论

当我们声明 unsigned/signed int count 时，unsigned/signed 是变量 count 的使用属性，int 是其容量属性。

所谓使用属性，就是当它存在寄存器或内存时，不管是 unsigned 还是 signed 本质是一样的，但对它进行访问时，就区别对待。

比如对 count 进行加法，unsigned 时用的是 ADD 指令，signed 时用的是 ADC 指令，其余减乘除也都类似地使用不同指令。

再来一个问题：把一个变量保存到文件里，再读出来，怎么知道它是有符号还是无符号？

答案是：如果你不在序列化时考虑符号，则反序列化时，无法知道原来的符号，把它赋值给什么类型的变量它就变成什么类型。

这也是 JSON 文本转对象后，要自己选择数据类型的原因，因为 JSON 文本没表示符号的语法。

结论

优化思路：理解本质，就能了解限制和优化方向。

UMUTech

云游戏开发指南【1】

实用参考

  1. 云游戏的架构设计和技术实现

    https://blog.csdn.net/RA681t58CJxsgCkJ31/article/details/79226317

  2. GamingAnywhere

    http://www.gaminganywhere.org

  3. OBS Studio

    https://github.com/obsproject/obs-studio

服务器架构

  • NVIDIA Grid 显卡

  • Windows 8 - 10，最好别用 7。

  • Sandbox 方案

一份授权 Windows 系统大约可以运行 40~50 个游戏实例。

音频

  • 服务器上设置 48000Hz 采样率；

  • 编码器采用 Opus，48000Hz，128kpbs

    1. 音频编码的延迟：需要一个 frame 才能编码，而等待一个 frame 需要时间。比如，48000Hz 的 samplerate 编码到 1024 samples/frame 的 AAC，一个 frame 需要的采集时间是 1000 * 1024 / 48000 = 21.3ms，这个只是采集的理论时间，应用程序的采集间隔还可能增大这个采集延迟，然后还有编码、传输、解码、播放延迟。

      Opus 的 frame size 默认是 960，相比 1024 的 AAC 理论上可以减少一点点延迟，1000 * 960 / 48000 = 20ms。

      Opus 的 frame size 还可以更小，比如 120，但不建议使用，因为 Windows 一次采集 480 samples，frame_size = 120 时，一次采集包含 4 frames，所以延迟和 frame_size = 480 其实是一样的。另外，live555 最小发送单位是 packet，而不是 frame，并且实现上 packet 要等待 960 samples 时长。

      128kpbs 的 Opus 音质几乎已经顶天了，人耳很难分辨，比 mp3 好太多了，网络上流行的高音质 mp3 都是 320kpbs 的。

    2. Opus 是开源并免费的，AAC 好的编解码器都是收费的。

流传输协议

  • RTSP

  • live555

    http://www.live555.com/

    UMU 之前用 live555 2017.07.18 版本时，发现它对 Opus 支持不好，需要改进，当前版本未测。

UMUTech

优化思维【1】字符串去空格

In place 版本

传入的字符串将被改变。

为方便复用，一般会实现 ltrim 和 rtrim 两个函数，然后 trim 函数调用这两者实现。

  • ltrim：从 str 头部开始找到非空格字符，偏移量记为 offset，将 str 左移（move）offset 个字符。

  • rtrim：从 str 尾部向头部找到非空格字符，偏移量记为 offset，将 str 截断为 offset。

一个想当然的实现：

1
2
3
4
trim(str) {
    ltrim(str)
    rtrim(str)
}

假设 str 是 x 个空格 + y 个非空格 + z 个空格，则以上代码需要把 y + z 个字符向左移动 x 个位置。

更好的实现是：

1
2
3
4
trim(string& str) {
    rtrim(str)
    ltrim(str)
}

由于先截断，剩 x + y，再去左移，只需要把 y 个字符左移 x 个位置。

优化思路：尽量减少复制，调整顺序也是优化手段。

Copy 版本

传入的字符串不会被改变，返回一个新的字符串。

一个复用前面代码的实现：

1
2
3
4
5
6
string trim_copy(string str) {
    // str is a copy
    rtrim(str)
    ltrim(str)
    return str
}

这个版本需要复制 x + y + z 个字符，ltrim 和 rtrim 里面都有找偏移量的代码可以复用，直接找到 y 个非空格字符是起点和终点，复制这 y 个字符就好了。

1
2
3
4
5
6
string trim_copy(const string& str) {
    // str is a copy
    l = lfind(str)
    r = rfind(str)
    return str[l, r]
}

优化思路：尽量减少复制。

move

strlen、strcpy、memmove 这类函数，都有一个优化思路：机器字长对齐，一次处理一个机器字。对于长字符串，效果显著。

优化思路：针对硬件特征调整策略。

UMUTech

修复 Clang 编译错误：error: expected unqualified-id

问题

今天编译 EOSIO/eos 出现一些 error: expected unqualified-id。

环境

  • 操作系统：macOS Mojave
  • 编译器：AppleClang 10.0.1.10010046
  • SDK：MacOSX10.14.sdk
  • Boost：1.69.0（1.67.0 也有问题，干脆用这个版本）

验证问题

1
2
3
4
5
6
7
8
9
#include <signal.h>

int main() {
  ::sigset_t sigset;

  ::sigemptyset(&sigset);
  ::sigaddset(&sigset, SIGCHLD);
  return 0;
}

编译输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Scanning dependencies of target signal
[ 50%] Building CXX object CMakeFiles/signal.dir/signal.cpp.o
/Users/umu/umutech/macos-cpp/source/study/posix/signal/signal.cpp:6:5: error: expected unqualified-id
  ::sigemptyset(&sigset);
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/signal.h:125:26: note: expanded from macro 'sigemptyset'
#define sigemptyset(set)        (*(set) = 0, 0)
                                ^
/Users/umu/umutech/macos-cpp/source/study/posix/signal/signal.cpp:7:5: error: expected unqualified-id
  ::sigaddset(&sigset, SIGCHLD);
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/signal.h:122:31: note: expanded from macro 'sigaddset'
#define sigaddset(set, signo)   (*(set) |= __sigbits(signo), 0)
                                ^
2 errors generated.
make[2]: *** [CMakeFiles/signal.dir/signal.cpp.o] Error 1
make[1]: *** [CMakeFiles/signal.dir/all] Error 2
make: *** [all] Error 2

解决

去掉 sigemptyset 和 sigaddset 前面的 :: 即可。因为他们是宏，宏都是全局的，用 :: 修饰反而错了，严格！

Boost 开发分支上已经修复：

https://github.com/boostorg/process/blob/develop/include/boost/process/detail/posix/wait_for_exit.hpp#L60

https://github.com/boostorg/process/blob/develop/include/boost/process/detail/posix/wait_group.hpp#L65

UMUTech

EOSIO 数据同步

作者: UMU @ MEET.ONE 实验

最近三个月尝试各种方案把 EOSIO 链上交易数据同步到数据库中，踩了不少坑，现总结一下经验。

1. 使用 MongoDB 插件同步 transaction_traces 和 action_traces

原始需求是要链上交易数据，所以先是把 transaction_traces 和 action_traces 都同步。

踩坑：无奈地发现速度跟不上，服务器的时间成本比较高，只能舍弃。

2. 使用 MongoDB 插件同步 transaction_traces

研究插件代码，发现 action_traces 是从 transaction_traces 拆出来的，是重复的，所以把 action_traces 去掉，这次成功追上主网区块高度。

踩坑：transaction_traces 在查询 actions 时不太方便，因为 actions 是放到 transaction_traces 内部的一个数组，要查询具体一个 action 就得分两步走，先在 MongoDB 查询出某个 trx，然后再 actions 数组里遍历。数据库使用端的工程师觉得这样太麻烦，无奈继续放弃这到手的肥肉。

3. 使用 MongoDB 插件同步 action_traces

明确 action_traces 才是客户端想要的后，就只同步 action_traces。

踩坑：action_traces 条数比 transaction_traces 多了三倍以上，又出现追不上区块的问题……

4. 使用 MongoDB 插件同步 action_traces，但只要 transfer 数据

客户端最关心的是 transfer 数据，既然跟不上，就舍弃其它数据。

踩坑：舍弃的数据后期不好补。

5. 考虑 kafka_plugin

有人说 kafka_plugin 同步数据很快，可以追上主网区块。

踩坑：从 kafka_plugin 代码就能看出它没有处理 action_traces，如果还要去后端再拿出来处理，再插入到 MongoDB 里，那开发成本和服务器成本一样又上去了。

6. 从 2019 年的区块开始同步

从 35058781 块开始，插入数据库。之前的区块（1 - 35058780）处理后，仅插入数据量相对很小的 account_controls、accounts、pub_keys，其它数据量大的表不插入。

做这个尝试很重要，因为发现重要的线索：

  • 大约在 2200 万块开始，nodeos 的处理速度下降很多，平均每块要 2-3ms，所以同步慢的原因在于跑 nodeos 的服务器的性能。

  • 在 1 开始的早期区块阶段，同时插入 transaction_traces 和 action_traces，并不能看出比只插入 action_traces 慢，说明 MongoDB 端压力很小。

7. 结论

  • 要追上主网区块高度，nodeos 机器性能要好，2.5GHz CPU 不够用。之前听闻 BOS 要求 BP 使用 4.0GHz 的 CPU，现在看起来也是有道理的……以性能成本换取时间。

  • MongoDB 集群，按之前的文章《为 EOSIO MongoDB 插件搭建高可用集群》的配置，插入阶段毫无压力。

  • 插件代码有些问题，需要优化，最明显的就是 queue_size 的设计不合理，打印处理时间太长的提示也不合理。

    • queue 函数是个模板，所有的 queue 都调用它，但 max_queue_size 和 queue_sleep_time 缺只有一份，这可能导致一个 queue 导致的 queue_sleep_time 加大，影响到其它 queue，即整体的休眠时间会无用地加大。

    • 打印处理时间没有按照 max_queue_size 变化，当 max_queue_size 设置大时，打印就很频繁，带来延迟。

  • 建议：一定要注意成本问题！如果查询量不是很巨大，找点友商的数据源用用就好了，自己搭建的成本好高……但如果查询量太大，或者友商卖太贵，以上经验就是很好的参考了。

UMUTech

Nodejs 实现监控告警

作者: UMU @ MEET.ONE 实验室

钉钉

  1. 选择要接受通知的群，群设置 - 群机器人 - 添加机器人；

  2. 复制 webhook URL，记为 webhook_url；

  3. 发送通知的代码：

1
const fetch = require('node-fetch')

fetch(webhook_url, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    "msgtype": "text",
    "text": {"content": text}
  })
}).then(function(res) {
  if (res.ok) {
    console.log('Dingtalk message sent!')
  } else {
   console.log('status = ' + res.status)
  }
})

Telegram

  1. 添加 @BotFather，发送 /newbot 命令，随提示逐步建立一个机器人，得到这个机器人的 token，记为 bot_token。

  2. 选择要接受通知的 Group 或 Channel，按以下任一方式取得 chat_id：

(1) 转发 Group 或 Channel 内的消息到 @getidsbot

(2) 通过 Web 版查看 Group 或 Channel 的 URL 中，p 参数 的值。

  • 如果是 Group，chat_id 为把 g 前缀替换为负号的负整数。比如 p=g268787210，则 chat_id = '-268787210'

  • 如果是 Channel，chatid 为 前部分，并把 c 前缀替换为 -100 的负整数。比如 p=c1383705039_968667419389618100，则 chat_id = '-1001383705039'

  1. 发送通知的代码：
1
2
3
4
const TelegramBot = require('node-telegram-bot-api')
const bot = new TelegramBot(bot_token, {polling: false})

bot.sendMessage(chat_id, text)