-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
メモリ消費を削減する #105
Comments
Google Cloud Functionsに音声合成部分を任せるという案が出ている。 メリット
問題点
|
Firebase Cloud Functions時代にLINEのAPI呼び出しに使ったことがあります。
について
とありますが、この5秒には辞書の読み込み時間とかも含まれていますかね(ずっと変数保持してくれなかった気がする)
について この辞書はどういうタイミングで変更されますか? 一番ありそうなのは、botが立っている側のサーバーで辞書を管理して、Cloud Functionsがそれにhttps経由でアクセスできるようにする感じですかね オーソドックスなやり方ですが、アクセス回数を減らすために、Cloud Functions側でキャッシュとして持っておいて、botサーバー側から変更をcloud functionsに(urlアクセスなどによって)通知して、通知があったら辞書を取り直すみたいな感じでしょうか |
辞書の読み込みといっても、結局のところストレージからメモリにコピーする処理なので音声合成本体に比べれば圧倒的に軽いのではと予測しています。 |
あ、なんだ、それくらいならそうでもいいですし、ただそれだと bot本体のリリースに応じて Cloud Functions 側をアップデートする必要が出ちゃうので、botサーバーがhttpで辞書データをホストしてfetchしにいくみたいなのでもいい気はします |
データ転送は無駄にCPU時間を食うのでそれは何とも言えませんね… |
グローバル変数を使うな!ということなので辞書をグローバル変数にしたりしないとなると辞書をrequireする手がよさそうです(githubからinstallするのもあり) |
そもそもGoogleにビルドさせるんじゃなくて自前でコンテナを用意できないんですかね |
んー、FaaS?のレベルだからどうなのかなーという感じです、調べたらでてきたりするのかな |
もしかして「辞書を保存する料金」がかかります? |
おっと…? |
追加辞書を含めるとvutd-shovelの辞書ファイル、特に
sys.dic
は453.3MBものサイズがある。OpenJTalk(特にMeCab)に渡すためにはこれをメモリにロードする必要があるが、メモリが限られた環境では重荷になる。
さらに、事前に辞書をすべてロードしておいた場合も、音声合成時に60MBの使用量の増加がみられた。
この増加分60MBがv1.0.0での#42 の原因になった可能性がある。
(つまり、辞書など諸々が600MBを占有する中、二つの音声合成が同時に発生したことによりさらに60*2=120MBが占有され、限界に到達したのではないかということ)
postgresの設定や、辞書をロードするタイミングを調整することで、メモリ消費を削減できないだろうか。
アイデア募集中。
The text was updated successfully, but these errors were encountered: