Сначала я собирался сказать, что мне больше нравится ваш текущий подход, потому что каждый процесс ничего не разделяет, и затем я понял, что, ну, возможно, все они используют один и тот же жесткий диск внизу. Таким образом, есть еще узкое место, где происходит раздор. Или, может быть, операционная система и контроллеры жестких дисков умело справляются с этим?
Я думаю, что вы хотите, чтобы запись журнала не замедляла потоки, выполняющие реальную работу.
Итак, запустите другой процесс на том же компьютере (с более низким приоритетом?), Который фактически записывает сообщения журнала на диск. Обменивайтесь информацией с другим процессом, используя не UDP, как предлагается, а память, которую процессы совместно используют. Также известный, как запутанно, как отображенный файл памяти. Подробнее о отображенных в память файлах . В моей компании мы обнаружили, что отображаемые в память файлы намного быстрее, чем шлейф TCP / IP для связи по одному и тому же блоку, поэтому я предполагаю, что это будет быстрее, чем UDP.
То, что у вас есть в общей памяти, для начала может быть std :: queue, где push-и-pops защищены мьютексом. Ваши потоки ISAPI будут захватывать мьютекс, чтобы поместить вещи в очередь. Процесс регистрации будет захватывать мьютекс, чтобы вытаскивать вещи из очереди, освобождать мьютекс, а затем записывать записи на диск. Мьютекс защищен только обновлением совместно используемой памяти, а не обновлением файла, поэтому теоретически кажется, что мьютекс будет удерживаться в течение более короткого времени, создавая меньше узкого места.
Процесс регистрации может даже изменить порядок написания, чтобы привести в порядок метки времени.
Вот еще один вариант: Contine должен иметь отдельный журнал для каждого процесса, но иметь поток ведения журнала в каждом процессе, так что основной критичный ко времени поток не должен ждать возникновения записи в журнал, чтобы продолжить его работа.
Проблема со всем, что я здесь написал, заключается в том, что вся система - аппаратная часть, ОС, способ работы многоядерного кэш-памяти L1 / L2 ЦП, ваше программное обеспечение - слишком сложна, чтобы ее можно было легко предсказать, просто подумав. Создайте несколько простых приложений для проверки концепции, установите для них время и испытайте их на реальном оборудовании.