Notices by 雪餅 (yukimochi@toot.yukimochi.jp), page 16

まずはここからしておくか。

+ETERNAL WIP+

machinery の Fork ちょっと真面目に考えてみるか。

金融工学の会社？？？ - ESGブック - 私たちは持続可能な未来のために金融市場に力を与えます。 https://www.esgbook.com/

Redis バックエンド以外を削って小さくした Fork 作りたいんよね。

いや、むしろ machinery 開発中は Grab にいたけど、最近メディア系に転職しているっぽい。
- https://uk.linkedin.com/in/richardknop

RichardKnop さんは、 Grab に就業中で忙しいっぽいんよね。

†??????? ????? ???????†
でも ETERNAL Maintain がされるとうれしい（無茶）

そもそも、開発が続くライブラリなさすぎ問題なんだよな。

新生キューライブラリ使いた～い！！！

Redis の利用容量さえ小さければ、いくらキューにたまっていても挙動が悪くならないので投稿の共通化をした。
今後は、 gzip で圧縮してやろうかと考えている。

これは、 v1.2.0 で改善はしてる。

リレーは、入力速度が出力速度を超えると平気で Redis が 2GB とかの dump.rdb を書き出し始めるので Redis 自体がレスポンスしなくなってくる。

Redis データたまりまくった時の挙動が厳しくなりがち。（永続化を無効にしていればたぶん問題ない）

結局キューがたまりまくった時にさばきが不調になるのは、 Redis がポンコツになっているときなので、 Rabbit MQ にしたらよくなりそう。

Rabbit MQ をバックエンドにすると安定するんじゃないかと検討してたりした。

そのせいでむだにライブラリがでかくてつらい。

参考までに RichardKnop/machinery はバックエンドをめっちゃ選べる。

サンプルのクライアントがゴミなので、自分で HTTP リクエストを送る前提になるけど。

0.0.1 の時に試して性能的につらかったのでそれ以降試してないけど、 v1.6.2 まで上がってる。