[Feature]:統計の自動化(日記の自然言語処理解析の最適化)

[usuyuki]

どのような機能か
ボタン実行から自動化へ。
これまでさんざん議論してきたが。
表示方法の変更もあってこれが良い気がしてきた。

最初のハードル高さ軽減としても。

[usuyuki]

あと金銭的余裕によるサーバー増強できるため。

ただVPSだと高いので、オンプレミスも検討。（ラズパイでの運用はできたので、ちゃんとしたサーバーとUPSあれば成り立ちそう）

メモリ16GBあればTrasnformerモデルが使えるようになる。

[usuyuki]

現状

• 現状のロジックが全体で動かす前提のコードになっているのでコードの変更が必要
• 全体統計で日記少ない時の挙動壊れをちゃんと見る
• 一緒に動かすことで激重spacy系のインスタンス化のコスパ挙げてる側面あるので若干悩ましい。（まとめてブン回すのがやっぱり効率良い）←Laravel octaneみたいにずっとメモリに保持できない？←ユーザーによってパイプ変えてるのできつそう。

ついでに改善したいこと

• 月データの生成で毎回データベースふっとばすのやっぱり微妙
  →selectで日付引っ張ってあるのはupdateないのはccreateがよさげ

[usuyuki]

↑
日記1つだけだとコストが悪い。
GiNZA(Spacy)のインスタンス生成がめちゃくちゃ重いので。

なので、デーモンで常駐させる的なことするのがよいかも？

[usuyuki]

Misskeyでのジョブキュー的な感じで、非同期かつ重くならない感じに流せるとよいのでは

↓こういう感じでサイドに混み具合表示しておきたい

[usuyuki]

ジョブキュー参考

misskey-dev/misskey#4451

https://github.com/OptimalBits/bull

Laravelにもあったのか……
https://readouble.com/laravel/9.x/ja/queues.html

https://readouble.com/laravel/9.x/ja/horizon.html

[usuyuki]

キューで月ごとと年ごとの統計処理をしたい

CPUとメモリの専有を一定値に制限して、その範囲でキューを動かし続ける。

夜間バッチ処理は間が空きすぎるので……

[usuyuki]

逆に今週のサマリーとか、ユーザーランクは夜間バッチ処理活用したい。