1

gen_server と gen_fsm を使用して OTP システムを実装しました。ソフトウェアを実行するために必要ないくつかの値を読み取る構成ファイルがあります。例は次のとおりです。

{values, [value1, value2, value3]}.

マクロを使用してこれらの値の 1 つを抽出しました

define(VALUES, my_utility:get_conf_value(values)).

問題は次のとおりです: ?VALUES は非常に頻繁に呼び出される可能性があるため、構成ファイルは何度も解析されるため、gen_fsm の gen_server の状態内に ?VALUES を埋め込み、必要なときにいつでも呼び出しで抽出する必要がありますか?

実際、#state{} の変更や呼び出しを行わなくても、構成ファイル内の値を変更するだけでソフトウェアの動作を変更できるため、以前の実装には本当に感謝しています。

あなたはどのソリューションを好みますか？

4

3 に答える 3

2

解決策は、要件によって異なります。パフォーマンスと「正確さ」。

考えられる解決策は、構成をプロセス状態に保ち、定期的に再読み取りすることです（ファイルの変更時刻が変更されているかどうかを確認します）。これは、2つの世界の間の良い妥協点かもしれません。

概要：

  • 毎回ファイルから再読み込み：常に最新ですが、不要なIOで遅くなります
  • 間隔を置いて再読み取りし、プロセス状態で保存します。読み取りは高速ですが、遅れています。
  • 手動での再読み取り：読み取りは高速ですが、遅れており、手動でトリガーする必要があります
  • 一度読み取り、プロセス状態で保存：読み取りが速く、更新するには再起動が必要

考慮されていない要件：セキュリティ、安定性（構成ファイルが破損していますか？）

于 2011-05-24T12:15:16.860 に答える
2

これは、実際には、最初に考えるよりもはるかに難しいトピックです。例えば ​​：

  • 構成はどのように変更されますか?
  • 変更された場合に通知する必要があるプロセスはありますか?
  • 構成を中間プロセス/状態に保存しますか? これはクリアしなければいけませんか？
  • すべての異なるノードのすべての異なるプロセスで全員が同じ構成を確認できるようにするにはどうすればよいでしょうか?
  • または、構成が正しくなくてもシステムは機能しますか?
  • 構成はどのくらいの頻度でアクセスされますか?
  • そこにはどのようなデータが保存されていますか?

したがって、現在のソリューションを分析するには:

  • 値が必要になるたびに構成ファイルを解析すると、これらの問題を気にする場合、遅すぎてガベージが大量に作成されます
  • ユースケースによっては、gen_server に値を要求するのも遅すぎる場合があります。
  • 多くのルックアップを行う必要がある場合、gen_server も過負荷になる可能性があります
  • データが大きい場合、gen_server とプロセスの間でコピーすると、
  • アプリケーションが複数のマシンで実行されていて、構成の不一致を許容できない場合は、可能な限り同じ時間に更新が行われるように調整する必要があります (これは、一貫性を気にする場合、私が考えることができるすべてのソリューションで行うことができます) )

別の解決策は、構成をコードとして保存することです。たとえば、解析変換を使用するか、実際のソース ファイルを生成することによって、特別な構成モジュールを作成できます。このソリューションでは、構成値は VM のコンスタント プールに存在し、それらを取得することで生成されるガベージをできるだけ少なくします (後でデータをどう処理するかによって異なります)。

于 2011-05-24T12:36:18.143 に答える
2

個人的には、構成をモジュールとして作成するのが最善の解決策だと思います。利点は次のとおりです。

  • 本当にとても速い
  • ホットコードチェンジで変更可能
  • 任意の形式の構成ファイル形式から機械で生成できます
  • コンパイルとホット コード スワップにより、「正しい」構成のみを無料でアトミックに更新できます。

PS: クラスター全体の構成変更については、ネットワーク モジュールの負荷 (シェルでは nl/1) を参照してください。

于 2011-05-24T16:12:55.413 に答える