Проблема архитектуры и производительности

Question

У меня вопрос по архитектуре / производительности.Я говорю о SIP-сервере, который обрабатывает множественные клиентские запросы одновременно.Я предполагаю, что каждый запрос обрабатывается в отдельном потоке.В конце процесса, соответствующая информация журнала запроса потока записывается в файл.Я хочу оптимизировать последнюю часть обработки.Я имею в виду, я хочу знать, какие альтернативы вы предлагаете вместо записи этой информации в файл.Зачем?Потому что запись в файл после обработки использует ресурсы, которые я бы использовал для обработки других поступающих запросов.

Во-первых, что вы думаете по этому вопросу?И, если вы думаете, что это «настоящий» вопрос (я имею в виду, что альтернатива может оптимизировать производительность), что вы предлагаете?

Я подумал о том, чтобы записать данные в очередь и использовать другой процесс INДРУГОЙ МАШИНЫ, который будет читать из очереди и записывать в файл.

Спасибо за ваши предложения

Answer 1

Если это НЕ требование, чтобы журнал записывался до возвращения запроса - т. Е. Регистрация не является частью атомарного ответа - тогда у вас есть возможность вернуть ответ и просто инициировать регистрациюaction.

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

Если требуется журналчтобы быть написанным ДО ответ получен, у вас все еще есть возможность использовать надежную очередь, такую ​​как MSMQ.

Answer 2

Я подозреваю, что сетевые издержки, связанные с переносом регистрации на другую машину, вероятно, создадут больше проблем, чем решат. Я бы пошел с решением @Nicholas - ставить в очередь логи в один поток на той же машине. Очередь позволяет ослабить, так что время от времени дисковая задержка уменьшается, и поток регистрации может сделать свои собственные оптимизации, например. ожидание, пока оно не будет иметь размер кластера журналов, прежде чем писать. Другие вещи, такие как открытие нового файла журнала каждый день или всякий раз, когда размер файла журнала достигает предельного размера, также намного проще, не влияя на производительность основного сервера.

Даже если вы входите в систему на другом компьютере, вы все равно должны ставить в очередь запись в журнал, чтобы уменьшить задержку в сети.

Если объекты журнала в очереди содержат, скажем, перечисление 'request' (например, ElogWrite, ElogNewFile, ElogPath, ElogShutdown), вы можете попробовать оба варианта - вы можете поставить в очередь запрос на поток журнала, чтобы закрыть его текущий файл журнала и откройте путь к файлу на сетевом компьютере во время выполнения - буфер очереди будет поглощать задержку выполнения этого.