суббота, 3 декабря 2011 г.

[prog] Диагностика vs Скорость

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

Однако жертвой погони за скоростью может стать не только код. На неделе разгоняя обработку ответов от удаленной системы столкнулся с тем, что изменив схему обработки, переместив большее количество действий на уровень БД, значительно потерял в диагностике происходящего. Ответы приходят в асинхронном режиме, какой-то запоздает, какой-то придет повторно, может даже совсем левый ответ поступить. Раньше обработка была медленнее, я делал больше запросов к БД и точно знал, почему ответ должен быть проигнорирован. А сейчас запросов к БД меньше, выполняются они быстрее, но я вижу только списки актуальных и неактуальных ответов. Причина неактуальности уже недоступна. Чтобы ее сохранить, нужно делать лишние манипуляции с данными, а это потеря скорости, что недопустимо.

Раньше было “ответ такой-то проигнорирован потому-то”, а стало “ответ такой-то проигнорирован”. И все. Такие дела.

PS. Усвоенная мной за последние десять лет мудрость: логов мало не бывает ;)

4 комментария:

Andrey Valyaev комментирует...

Логи, это хорошо... Но это палка о двух концах.

Они замедляют приложение. У вас логи отключаются как-то? детализация регулируется?

Я в своем проекте борюсь с сообщениями. У нас нет другого способа мониторинга. Логи у нас есть, но они существуют для других людей, для администраторов, и для нас не несут почти никакой пользы. :)

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

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

А еще они загромождают код.

Неоднозначно это все.

eao197 комментирует...

>У вас логи отключаются как-то? детализация регулируется?

В принципе, сообщения в логах у нас классифицируются и ранжируются (error/logic, lowest/low/normal/high/highest приоритет). Но на практике это практически никогда не используется при фильтрации. Нам намного чаще приходится добавлять логирование, чем уменьшать его.

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

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

jazzer комментирует...

Это же относится и к скорости разработки ;)

eao197 комментирует...

@jazzer:

И к скорости разработки ;)

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