皆さん、こんにちは。
Difyを使ってゲームパフォーマンスデータのリアルタイム監視アシスタントを構築しようと試しているのですが、外部ソースからの高頻度データ注入 (rapid-fire data injections) をプラットフォームが処理する際に、大きなボトルネックに直面しています。ローカル環境からテレメトリーをプルするワークフローを設定しようとしているのですが、Difyの「HTTPリクエスト」ノードが、リクエスト頻度が特定のしきい値を超えるとハングアップしたり、429エラーを返したりするようです。
スクリプト処理をより軽量に最適化する方法を探していたところ、このサイトに関するブログ記事で、実行を効率化するための興味深い方法がいくつか紹介されているのを見つけました。そこで、blox fruitスクリプトや同様の高アクティビティ自動化ツールをDify DSLワークフローの構造化の参考に成功した方がいらっしゃるか、疑問に思いました。特に、「変数アサイナー」ノードを使用して、これらの入力スクリプト呼び出しがLLMノードに到達する前にバッファリングする方法があるのか、それともローカルスクリプトとDify APIの間にRabbitMQのようなより堅牢なキューイングシステムを導入すべきなのか、具体的に知りたいです。
また、外部スクリプトがタイムアウト後に再接続しようとすると、「会話ID (Conversation ID)」が無効になるという関連する問題も発生しています。Difyクラウド版では、セルフホスト型Dockerインスタンスと比較して、これらの種類の自動化されたバックグラウンド実行に対するレート制限がより厳しくなっていることに気づいた方はいらっしゃいますか？これらのレイテンシースパイクを避けるために、スタック全体をローカルサーバーに移行すべきか、それともこれらの外部トリガーをサンドボックス化してメインワークフローを溢れさせないようにする特定の「条件」ノードロジックがあるのか、決めかねています。UIをクラッシュさせることなくデータフローを安定させる方法について、何かアドバイスがあれば大変助かります！