2016-12-12 3 views
0

Нам недавно пришлось переключиться с .txt на logfiles на .html. Причины того, что мы могли бы легко фильтровать категории, применять цвета к тексту и т. Д.Как оптимизировать большой HTML-файл

Наши лог-файлы - это простой старый html-файл со всеми включенными ресурсами (встроенный css, встроенный js, ...). Каждое сообщение является <div> с некоторыми классами, применяемыми (например, timestamp или category_foo)

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

У нас также есть система фильтрации, которая использует javascript для скрытия всех сообщений, содержащих определенный класс (для фильтрации по категориям).

Одна из наших оптимизаций заключалась в том, чтобы не изменять элементы DOM напрямую, а вместо этого добавить новый тег <style> в голову html. Таким образом, мы можем легко добавить display:none; ко всем сообщениям. Это уже многое помогло, но его недостаточно.

Каким образом мы могли бы оптимизировать это? В Chrome загрузка даже файла размером 30 Мб занимает много минут. Можно ли каким-то образом оптимизировать файл, чтобы облегчить загрузку браузера? Возможно, мы можем каким-то образом разбивать страницы на журнал, хотя все содержимое находится внутри html-файла?

Чтобы сделать запись как можно быстрее во время выполнения, наше приложение начинается с написания «шаблона» html. И тогда он просто продолжает добавление строки как этот

<div class='categoryInfo'>Some Info Text</div>

+0

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

+2

Я собирался сказать то же самое! Дамп всех журналов в базу данных, тогда вы можете создать полный текстовый индекс на все. Вы используете «веб-страницу» в качестве базы данных, и это не то, что было предназначено для ... – Vi100

+0

Я предполагаю, что ваша фильтрация js срабатывает после того, как браузер загружает и отображает html, поэтому в вашей начальной загрузке вы фактически показываете все, что может быть так долго.Я бы добавил отображение: none к контейнеру всех сообщений, а затем в js фильтрует сообщения, которые вы действительно хотите, а затем удаляете отображение: none из родительского контейнера. Таким образом, вы также можете разбивать страницы на то, что вы показываете. Все зависит от того, что занимает минуты, это рендеринг экрана или html load + html parsing, хотя – juvian

ответ

0

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

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

Альтернативой будет сделать ваш файл журнала более понятным для машины и изучить инструменты, которые затем помогут вам читать, фильтровать, искать его. например:

1

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

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

Смежные вопросы