Вход в JSON Влияние на производительность


22

Я вижу все больше и больше статей о входе в JSON. Вы также можете найти его в блоге NodeJS. Почему всем это так нравится? Я вижу только больше операций:

  • Пара новых объектов создается.
  • Stringifying объекты, которые включают в себя либо вычисление длины строки, либо несколько распределений строк.
  • Собираю все дерьмо, которое было создано.

Есть ли какой-нибудь тест на производительность при использовании JSON-журналов и регулярных строковых журналов? Люди используют JSON (для регистрации) в корпоративных проектах?

Ответы:


36

Ведение журнала JSON позволяет программно анализировать файл журнала, даже если формат изменился во времени .

Хороший пример - журналы Apache. По умолчанию Apache использует commonформат для access.log:

"%h %l %u %t \"%r\" %>s %b"

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

В какой-то момент вы вводите субдомены в свое приложение и включаете их virtual_hostв свои журналы (просто так вы можете отлаживать, если возникают проблемы с одним из субдоменов):

"%v %h %l %u %t \"%r\" %>s %b"

Ваш синтаксический анализатор не использует его virtual_hosts, но вам все равно необходимо адаптировать его к:

  • принять новый формат журнала (обратите внимание %vна заголовок формата журнала)
  • все еще поддерживает старый формат журнала (для старых файлов журнала)

Но если вы войдете в JSON , ваш анализатор даже не заметит добавленное поле и может с радостью проанализировать как новые, так и старые журналы. А некоторые другие парсеры могут использовать добавленные поля, если они существуют .

И, конечно, для вас анализ JSON проще, чем написание regexpsдля разбора строковых логов.


10
Прекрасный пример.
Флориан Маргейн

27

Если ваша машина работает так близко к своим пределам, что такие проблемы действительно имеют значение, у вас, скорее всего, будут более серьезные проблемы. Хотя могут быть исключительные ситуации, когда это имеет какое-то значение, многие приложения (возможно, большинство) работают на машинах, для которых разница, если вы регистрируете JSON, простой текст или записи в базе данных, не имеет значения вообще. В любом случае, объекты, строки и другие преобразования должны выполняться в большинстве случаев (если вы не ведете журнал в двоичном формате?), Может быть, вы его не увидите, потому что вы используете классы по умолчанию, которые обрабатывают его в фоновом режиме (например, если вы пишете в базу данных).

Если вам нужны оценки производительности для этого, вам нужно будет сделать их самостоятельно на компьютере, на котором вы хотите запустить свой код, и в среде программирования, которую вы используете каждый день. Если есть большие накладные расходы или какие-либо вообще, зависит от многих вещей. Например, если вы пишете веб-сайт на Ruby on Rails, ваши данные в большинстве случаев являются хэшем, преобразование которых в JSON практически ничего не стоит, поскольку внутреннее представление не так уж далеко от того, что вы хотите написать (и это типично для кода Rails, чтобы постоянно разбрасывать такие объекты и структуры данных).

Преимущества снова зависят от ваших инструментов. Если у вас есть JSON, встроенный в ваши библиотеки, вы можете легко прочитать его и отобразить в некоторой форме. Снова в качестве примера. Предполагая, что у вас есть интерфейс администратора для вашего веб-сайта и вы хотите показать некоторую информацию журналирования, хранящуюся в JSON, вы можете сделать это для чтения и отображения в виде HTML в Ruby в одной строке кода в некоторых случаях.


1
Бьюсь об заклад, вы не заботитесь о выбрасывании микросекунд ...
Rhymoid

@Rhymoid нет, я предпочитаю использовать свое время для решения реальных проблем.
Торстен Мюллер

3
@Rhymoid Есть ситуации, когда выбрасывать микросекунды, конечно, плохо. Я также думаю, что 99,9% программистов будут писать код там, где этого нет. Например, большинство веб-фреймворков делают больше, чем мне нужно, и это накладные расходы. Но вместе с ним поставляется полный набор тестов и средств безопасности, а также экономит сотни часов, когда я сам его кодирую. За дополнительные расходы, которые моя компания не тратит на его создание с нуля, они могли бы финансировать удвоенное оборудование, если бы им было нужно (хотя это, вероятно, также быстрее, чем все, что я мог бы построить сам в любом случае ...) В конечном счете, микросекунды не имеют значения.
CorsiKa
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.