В фильтре ISAPI какой хороший подход для общего файла журнала для нескольких процессов?

Question

У меня есть фильтр ISAPI, который работает на IIS6 или 7. Когда есть несколько рабочих процессов («веб -сад»), фильтр будет загружен и запускается в каждом w3wp.exe.

Как я могу эффективно позволить фильтру регистрировать свою деятельность в одном консолидированном журнале?

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

• Должно быть минимальное утверждение для журнала. Веб -сайты могут служить 100 запросов в секунду.

• Строгий порядок времени предпочтительнее. Другими словами, если процесс № 1 w3wp.exe издает сообщение в T1, то процесс № 2 издает сообщение в T2, то процесс № 1 издает сообщение на T3, сообщения должны отображаться в правильном порядке времени в файле журнала.

Текущий подход, который у меня есть, заключается в том, что каждый процесс владеет отдельным файлом журнала. Это имеет очевидные недостатки.

Некоторые идеи:

• Выдвините один из W3WP.exe, чтобы стать «владельцем файла logfile» и отправьте все сообщения журнала в этом специальном процессе. У этого есть проблемы в случае переработки рабочих процессов.

• Используйте ОС MUTEX, чтобы защитить доступ к журналу. Это достаточно высокого показа? В этом случае каждый w3wp.exe будет иметь файл в одном файле файловой системы. Должен ли я сделать что -то файл журнала после каждой записи? Это сработает?

какие-либо предложения?

Answer 1

Сначала я собирался сказать, что мне больше всего нравится ваш текущий подход, потому что каждый процесс ничего не разделяет, а затем я понял, что, ну, вероятно, все они разделяют один и тот же жесткий диск под ним. Итак, есть еще узкое место, где происходит споры. Или, может быть, ОС и контроллеры жесткого диска действительно умны в обращении с этим?

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

Итак, запустите другой процесс на той же машине (более низкий приоритет?), Который фактически записывает сообщения журнала на диск. Сообщайтесь с другим процессом, используя не UDP, как предполагалось, а скорее память, которой делятся процессы. Также известно, смущающе, как файл с отображением памяти. Больше о Память отображают файлы. Анкет В моей компании мы обнаружили, что файлы с отображением памяти были намного быстрее, чем Loopback TCP/IP для связи в том же поле, поэтому я предполагаю, что это будет быстрее, чем UDP.

То, что у вас на самом деле есть в вашей общей памяти, может быть, для начала, std :: queue, где толчки и всплывают защищены с помощью мутекса. Ваши нити ISAPI захватили бы мутекс, чтобы положить вещи в очередь. Процесс ведения журнала захватит мутекс, чтобы снять вещи из очереди, отпустить мутекс, а затем написать записи на диск. Мутекс защищен только обновлением общей памяти, а не обновлением файла, поэтому теоретически кажется, что мутекс будет удерживаться в течение брифирного времени, создавая меньше узкой полости.

Процесс журнала может даже переоценить порядок того, что он пишет, чтобы получить временные метки в порядке.

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

Проблема со всем, что я написал здесь, заключается в том, что вся система - аппаратное обеспечение, ОС, способ, способный многокроугольный процессор L1/L2 Cache, ваше программное обеспечение - слишком сложна, чтобы быть легко предсказуемым, думая, что это через. Кодируйте несколько простых приложений для подтверждения концепции, придайте им несколько времен и попробуйте их на реальном оборудовании.

Answer 2

Будет ли здесь смысл регистрация в базе данных?

Answer 3

В прошлом я использовал систему журнала на основе UDP, и я был доволен этим видом решения.

Журналы отправляются через UDP в процесс логарифмического коллектора, который он отвечал за его сохранение в файле на регулярной основе.

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

Я надеюсь, что это помогает.

Answer 4

Вместо ОС Mutex для управления доступом к файлу, вы можете просто использовать механизмы блокировки файлов Win32 с помощью lockfile () и unlockfile ().

Answer 5

Мое предложение - отправка сообщений асинхронно (UDP) в процесс, который возьмет на себя ответственность за запись журнала.
Процесс будет:
- Один приемник потока помещает сообщения в очередь;
- Один поток отвечает за удаление сообщений из очереди, введенного в список заказанного времени;
- Один из сообщений мониторинга потока в списке и только сообщения с длиной времени, превышающей минимальный, должен быть сохранен в файле (чтобы предотвратить задержку сообщения, чтобы быть записанным вне заказа).

Answer 6

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

Answer 7

Отслеживание событий для Windows, включены в Windows Vista, а затем - отличные возможности для этого.

Выдержка:

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