читать много раз конфигурационный файл или использовать статус gen_server?

Question

Я реализовал систему otp, используя gen_server и gen_fsm. Существует файл конфигурации, который нужно прочитать для некоторых значений, которые необходимы программному обеспечению для запуска, например:

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

Я использовал макрос для извлечения одного из этих значений

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

Вопрос заключается в следующем: поскольку? VALUES можно вызывать очень часто, и, следовательно, файл конфигурации анализируется много раз, я должен встроить? VALUES в состояние моего gen_server gen_fsm и извлекать его с помощью вызова в любое время нужно это?

На самом деле я действительно высоко оценил предыдущую реализацию, потому что можно изменить поведение программного обеспечения, просто изменив значения в файле конфигурации, без каких-либо изменений или вызова #state {}.

Какое решение вы предпочитаете?

Answer 1

На самом деле эта тема намного сложнее, чем кажется на первый взгляд.Например:

• Как изменяется конфигурация?
• Есть ли какие-либо процессы, о которых следует уведомлять в случае их изменения?
• Сохраняете ли вы конфигурацию в каком-то промежуточномпроцесс / состояние?Должно ли это быть очищено?
• Как вы гарантируете, что все видят одинаковую конфигурацию во всех разных процессах на всех разных узлах?
• Или ваша система способна функционировать даже с неверной конфигурацией?
• Как часто осуществляется доступ к конфигурации?
• Какие данные вы там храните?

Итак, для анализа ваших текущих решений:

• Разбор файлов конфигурации каждый раз, когда вам нужно, значение будет слишком медленным и создаст слишком много мусора, если вы заботитесь об этих вопросах
• Запрос Gen_server для значения также может быть слишком медленным, в зависимости от вашего варианта использования.
• Если вам нужно выполнить много поисков, gen_server также может быть перегружен
• Если данные большие, копирование между gen_server и вашим процессом может
• Если ваше приложениеработает на нескольких компьютерах, и вы не можете допустить несогласованность в конфигурации, вы должны организовать обновление, чтобы оно произошло как можно ближе кв то же время (это вы могли бы иметь с любым решением, о котором я могу подумать, если вы заботитесь о согласованности)

Другим решением будет сохранение конфигурации в виде кода.Например, у вас может быть специальный модуль конфигурации, который вы создаете, используя преобразование синтаксического анализа или генерируя фактический исходный файл.При таком решении значения конфигурации находятся в постоянном пуле виртуальной машины, и их выборка создает как можно меньше мусора (в зависимости от того, что вы будете делать с данными позже).

Answer 2

Лично я считаю, что лучшее решение - это конфигурировать как модуль. Преимущества:

• Действительно очень быстро
• Может быть изменено путем горячей замены кода
• Может быть сгенерирован машиной из любых форматов файлов конфигурации
• Компиляция и горячая замена кода дает вам атомарное обновление только по «правильной» конфигурации бесплатно

P.S .: См. Загрузку сетевого модуля (он же nl / 1 в оболочке) для изменения конфигурации всего кластера.

Answer 3

Решение будет зависеть от ваших требований.Производительность против «правильности».

Возможное решение - сохранить конфигурацию в состоянии процесса и регулярно перечитывать ее (проверяя, изменилось ли время изменения файла).Это может быть хорошим компромиссом между двумя мирами.

Резюме:

• Повторное чтение из файла каждый раз: всегда актуально, но медленно с ненужным IO
• Перечитывание с интервалом, сохранение в состоянии процесса: быстрое чтение, но с отставанием
• Перечитывание вручную: быстрое чтение, но с отставанием и требует ручного запуска
• Чтение один раз ихранить в состоянии процесса: быстро читать, требуется перезагрузка для обновления

Требования не учитываются: безопасность, стабильность (поврежден файл конфигурации?)