C ++ AccessLog Parser, использующий MMap / OpenMP - проблема с правильным подсчетом событий веб-доступа к потоку мультимедиа

Question

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

Я создал CLI-инструмент для анализа журналов доступа веб-сервера.Я сосредоточился на производительности и гибкости в использовании.

Поэтому я использую MMap для чтения файлов журнала в память, а затем передаю отображенный в памяти символ * в параллельный цикл обработки OpenMP.

В параллельной ompДля цикла я просто анализирую несколько информативных подстрок из каждой LogString, используя boost :: regex_search, и сохраняю данные о событиях в локальном пользовательском потоке типа объекта LogEvent.

После создания этого объекта LogEvent-Object изВ текущей строке я добавляю LogEvent к вектору и продолжаю синтаксический анализ следующей строки и т. д.

Хитрость заключается в том, что я анализирую файл конфигурации пользователя при запуске программы.Пользователь может определить несколько «полей данных», указав имя поля и RegEx, которые будут соответствовать данным.

Например:

Time = \d{2}\/\w{3}\/\d{4}
IP = \d{1,3}\.\d{1,3}.\d{1,3}.\d{1,3}
Object = \d{2,8}\_w\d{1,3}.mp4|\d{2,10}.flv

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

Например:

field_0 = %IP%
field_1 = %Object%
field_2 = %Time%

Выходные строки могут выглядеть следующим образом:

10.20.30.1;video_xyz.flv;Jul/23/2011:11:12;3 
10.20.30.1;video_xyz.flv;Jul/23/2011:11:17;1 
10.20.30.1;video_xyz.flv;Jul/23/2011:11:18;12
10.11.30.1;video_xyz.blabla.mp4;Jul/23/2011:11:12;3  

У меня проблема в том, что потоковое видео-file вызывает несколько событий доступа в журнале.Я не могу распознать кого-то, кто просто перезагружает / буферизирует поток, потому что разные клиентские платформы ведут себя по-разному при генерации кодов ответа сервера.

Сейчас я считаю события несколько раз, что часто неправильно.

Как я могу справиться с этой проблемой?Это довольно общее, я знаю, но если вы подумаете о моей программе и о том, как я ее описал, вы скоро увидите, что проблему с дизайном моей программы трудно решить.

Я нашел тот или иной способ обхода, ноэто всегда очень плохо влияет на производительность и не является правильным решением.

Каким-то образом я должен избегать добавления этих LogEvents к вектору LogEvent-Objects во время синтаксического анализа, потому что до этого момента строки все еще находятся в правильном хронологическом порядке.Для того, чтобы я мог сравнить текущую строку с предыдущей и т. д.

После этого начинается критическая фаза omp и результаты локального потока объединяются, и если я хочу проверить на неправильное количество совпадений, я будуприходится искать по всему массиву данных, который является nogo.

Я надеюсь, что моя проблема достаточно ясна.Есть идеи?(не знаю, поможет ли пример кода, потому что это больше проблема дизайна, я думаю) ...

Answer 1

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

При анализе строк я всегда получаю IP-адрес и целевой элемент из каждой строки журнала.

Iиметь локальную карту потока, которая хранит IP-адрес в качестве ключа и целевой объект (например, видеопоток) в качестве значения.

всякий раз, когда я хочу посчитать лог-событие, я проверяю ранее, если обрабатываемый в данный момент IP-адрес LogsStrings уже являетсяКлюч моей ветки локальной карты.

Если это не так, можно посчитать событие.И я добавляю текущий IP в качестве ключа и Object как значение, что означает, что я обновляю последний объект, к которому был осуществлен доступ для этого конкретного IP.

Если это уже ключ моей карты, я проверяю, является ли значение этого ключа (целевым объектом)item) совпадает с моей текущей целью LogStrings.

Если это так, это может означать, что в последний раз этот пользователь обращался к чему-либо на моем сервере при обращении к тому же видеопотоку.

Я будупродолжайте считать события с этого IP-адреса только после того, как объект изменился.

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

Это работает так же, как и обратный серый список.любой ip просто подсчитывается один раз, а затем блокируется от подсчета до тех пор, пока не будет сгенерирована новая подпись из-за нового объекта.

Конечно, это также влияет на производительность, поэтому, если у вас есть более интересные идеи, смело отвечайте:P