Как можно ускорить работу Exception?

Question

[HellWalk]

С 2008 года с php работаю, а только сегодня узнал, что его Exception очень сильно замедляют работу:

json с 15 тысяч позиций (данные по каждой, разумеется, надо провалидировать) с Exception на каждой позиции обрабатываются 6 минут

Без исключений этот же объем данных обрабатывается за 2 секунды

Что еще интереснее, что чем больше исключений - тем дольше обрабатываются новые:

5000 позиций (все с ошибками) - 47 сек.
10000 позиций (все с ошибками) - 192 сек.
15000 позиций (все с ошибками) - 375 сек.

Если переделать валидацию с Exception на простую проверку строки:

$error = $this->handle($json);
if ($error === '') {
    // логируем что все ок
} else {
    // логируем ошибку
}

То тот же json с 15 тысяч позиций, с ошибками в каждой обрабатывается за те же 2 секунды.

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

Но, возможно есть способ как-то ускорить Exception? Надежды мало, но вдруг кто-то знает способ.

Comments

[Saboteur]

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

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

[Максим Федоров]

Saboteur, при работе с БД может так произойти, что для ORM произошла исключительная ситуация, а для скрипта и текущей логике — нет.
Вот и 15тыс исключений

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

[HellWalk]

Saboteur, вы говорите о том же, о чем я уже написал - об отказе от Exception

[Ипатьев]

HellWalk, ну вот уже надо перестать говорить и начинать делать

[Vitsliputsli]

HellWalk, неа, он говорит об использовании исключений по их назначению - для исключительных ситуаций.

[Vitsliputsli]

Максим Федоров, а можно пример?
Я понимаю ситуацию, когда мы обратились к базе, а там не нашлось объекта (например, он динамически создается) - упали в исключение, обработали его, т.е. создали нужный объект, и вернулись к нормальной работе.
Но что за ситуация, когда нужно 15000 исключений?

[HellWalk]

Vitsliputsli, мне не интересно сейчас спорить по поводу терминов.

Для меня удаление 99 из 100 Exception в коде - это удаление exception. Для кого-то это "правильное использование" (хотя для меня это костыли), сути правок не меняет.

[Максим Федоров]

Vitsliputsli, 15 тыс операций в одном скрипте, каждая операция сталкивается с исключением (Guzzle например или ORM, не суть важно)

[Vitsliputsli]

HellWalk,

мне не интересно сейчас спорить по поводу терминов.

Для меня удаление 99 из 100 Exception в коде - это удаление exception. Для кого-то это "правильное использование" (хотя для меня это костыли), сути правок не меняет.

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

[Vitsliputsli]

Максим Федоров, да это я понял, но мне интересен пример бизнес-логики, которая при нормальной работе использует 15000 исключений.

[Максим Федоров]

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

[Vitsliputsli]

Максим Федоров, 15000 исключений при работе с СУБД, это 15000 ошибочных sql-запросов, так? Я не могу придумать ни одного варианта, когда такое было бы оправдано.

Answer 1

[Ипатьев]

"Если вас беспокоит скорость работы исключений, вы что-то делаете неправильно"

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

Ошибка валидации при валидации - это не исключительная ситуация, а совершенно нормальная. Часть бизнес-логики. То есть в процессе валидации всего массива данных исключения кидаться не должны.
Если исключения используются для управления ходом выполнения программы - это УЖЕ ошибка.

По результатам валидации исключение может кидаться ОДНО. В самом конце. По результатам валидации всего набора данных. Или не кидаться - зависит от конкретной бизнес-логики. Но если и кидать, то только одно, по результатам.
Это будет правильное использование исключений, которое вообще никак не скажется на скорости работы кода.

Comments

[HellWalk]

Что за бред я только что прочитал?

Исключение может кидаться ОДНО. В самом конце.

Может еще и логику всего приложения в одном файле писать?

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

[Ипатьев]

HellWalk, а где я здесь писал про "приложение" и "всех классов"?
Здесь несколько раз подчеркнуто, что речь идет об одном конкретном участке - валидации.
Но специально для невнимательных подчеркну ещё раз.

Ещё вопросы будут?

[Daria Motorina]

Зачем тратить ресурсы на обработку всех данных, если ошибка валидации оказалась в начале или середине?
Собрать отчет об невалидных данных по факту проверки и кидать одно исключение это не одно и то же.

[Ипатьев]

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

Но если отвечать на ваш вопрос, то стратегия "продолжать при ошибке" является совершенно стандартной. Когда вы в своем приложении на ларавели валидируете форму, вы же не прерываете валидацию при первой ошибке (если только специально не укажете фильтр bail).
То же самое относится и к валидации больших наборов данных - обычно нам надо получить отчёт обо всех ошибках, а не падать после первой же.

[HellWalk]

Ипатьев,

Ещё вопросы будут?

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

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

Но отказ от стандартных исключений везде где они нужны - это будет как раз вынужденный костыль, ради быстродействия.

[Ипатьев]

HellWalk,

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

Для функции валидации, невалидный инпут не является исключительной ситуацией. А наоборот - совершенно стандартной, для которой эта функция и придумана.

Л - Логика.
Как только вы её постигнете, всё встанет на свои места.

[Ипатьев]

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

Для функции, которая использует некие данные, невалидный инпут является исключительной ситуацией.
Для функции же, повторюсь, которая валидирует некие данные, невалидный инпут не является исключительной ситуацией. И, следовательно, исключение она кидать не должна.
Всё ведь очень просто.

[HellWalk]

Ипатьев,
Вы так привязались к слову валидация, а что если я сказал это для простоты, чтобы не вываливать на читающего всю сложность логики?

[Ипатьев]

Но отказ от стандартных исключений везде где они нужны - это будет как раз вынужденный костыль, ради быстродействия.

Вы опять натягиваете сову на глобус.
Вас никто не призывает вообще отказаться от исключений.
Свой частный случай с 100500 брошенных исключений вы пытаетесь растянуть на весь процесс разработки.
Поймите, исключение - это исключительная ситуация. То есть случается очень редко. И никакого влияния на быстродействие не оказывает. Пусть даже потенциально его может кинуть любая функция. Ради бога.
Даже функция валидации может кинуть исключение - в том случае, если она не может выполнить свою работу.
И это никак не скажется на быстродействии.
Логично?

[Ипатьев]

HellWalk, да что угодно. Если приложение у вас кидает 100500 исключений, то это не исключительная ситуация. То есть вы используете инструмент не по назначению. В этом и проблема, а не в "быстродействии"

[HellWalk]

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

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

Answer 2

[Максим Федоров]

на расходы конкретно на исключения для 15 000 вызовов (на каждую строку по 1 исключению) будут около 0.01 секунды (сотая секунды крч) для моего локального компа (много, но и данных много)

Пруф

$error = $this->handle($json);
if ($error === '') {
// логируем что все ок
} else {
// логируем ошибку
}

Тут заменено не только это, а заменено что-то внутри в handle(), тк не летит исключение

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

в 15 тыс новых объектов проблемы может не быть. Такие задержки по времени выглядят как проблема на уровне логирования исключений, тк I/O операции над файлом долгие, а сбор трейса исключений и его запись — долгие потенциально.
Уйдя от исключений вы возможно ушли и от логирования исключений.

Comments

[Ипатьев]

а сбор трейса исключений и его запись — долгие потенциально.

ну вот кстати да, в этом минималистичном тесте и трейс никакой.
А в живом проекте может счет идти на сотни килобайт.

[Максим Федоров]

Ипатьев, сотни килобайт еще не беда сами по себе... а вот запись этих килобайтов в файл — потенциальное дикое замедление

[HellWalk]

Уйдя от исключений вы возможно ушли и от логирования исключений.

Логирование делается, перепроверил.

Я не стал в вопросе погружать по все тонкости обработки. Для оптимизации там уже была выброшена ORM, добавлены свои псевдо-сущности, которые группировали insert'ы в базу (что также сильно ускоряет обработку) и прочие оптимизации. Сейчас вот до отказа от Exception дошло.

Если говорить о том, почему ваш пример отрабатывает быстро... возможно дело в цепочках исключений - когда исключение бросает один класс, потом его перехватывает другой и так по цепочке. Плюс сам stack trace видимо большой.

[Максим Федоров]

Я не стал в вопросе погружать по все тонкости обработки

Логирвоание исключений вам замедляют... сами исключения не замедляют (точнее оооочень не значительно)

Сейчас вот до отказа от Exception дошло.

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

Для оптимизации там уже была выброшена ORM

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

Я не стал в вопросе погружать по все тонкости обработки

Если на вещи смотреть мутно, то и вещи будут казаться мутными
((c)мой друг-юрист сказал так в 2010г)

[HellWalk]

Максим Федоров,

Логирвоание исключений вам замедляют... сами исключения не замедляют

На основании чего сделан такой вывод?

[Максим Федоров]

HellWalk, на основании того, что исключения как объекты не могут замедлить на такую разницу, а I/O операции могут,
что является известным и причиной целых концепцией асинхронного программирвоания для I/O операций над файлами/сетью и прочим

[HellWalk]

Процитирую себя:

15000 позиций (все с ошибками) - 375 сек.

Если переделать валидацию с Exception на простую проверку строки:

...

То тот же json с 15 тысяч позиций, с ошибками в каждой обрабатывается за те же 2 секунды.

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

[Виталий Хоменко]

HellWalk, вы хотите решить проблему или нет?

Сколько у вас за эти 6 минут работы скрипта с исключениями производится записей в лог? Они же есть, верно?
Вам пытаются объяснить что сами по себе исключение не могут замедлить работу с 2х секунд до 6ти минут.
Если у вас там тысячи записей в логи, то скорее всего именно они являются причиной, т.к. каждая запись в лог это обращение к ФС на запись

[Армянское Радио]

Виталий Хоменко, хуже всего, что это обращение с fsync, а если в качестве накопителя у нас блинно-головочный комбинат, 15000 fsync / 50 (IOPS с ушатанного диска. Если там ext4, это как раз по две записи с синком на одну запись в лог - одна в журнал, одна в инод ) / 60 (секунд в минуте) грубо будет как раз искомые 6 минут.

[HellWalk]

Виталий Хоменко,

вы хотите решить проблему или нет?

Если вы не заметили (перечитайте вопрос еще раз) - я её уже решил. А сюда зашел послушать другие варианты. На что получаю ответы "ты не шаришь, надо делать так", и предлагают то, к чему я уже сам пришел.

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

Аргументы "этого не может быть потому что не может быть" - не аргументы.

P.S.

Если у вас там тысячи записей в логи, то скорее всего именно они являются причиной

Уже писали и уже отвечал - все нормально, 15 тысяч записей записывается в базу за 2 секунды.

[Виталий Хоменко]

HellWalk, вот как. Тяжело с таким подходом развиваться, но дело ваше. Удачи тогда

[HellWalk]

Виталий Хоменко,

Тяжело с таким подходом развиваться, но дело ваше

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

[Виталий Хоменко]

HellWalk, вам показалось. Давайте не продолжать этот диалог, в нем нет смысла

[Максим Федоров]

HellWalk,

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

А вот это обидно, так как именно я на это указал в своем ответе и тут вам разные люди пытаются просто это разжевать :(

Такие задержки по времени выглядят как проблема на уровне логирования исключений, тк I/O операции над файлом долгие, а сбор трейса исключений и его запись — долгие потенциально.
Уйдя от исключений вы возможно ушли и от логирования исключений.

[Максим Федоров]

HellWalk, писал как-то летом решение по генерации фидов на Golang

ТАк вот, когда я заменил запись каждой строки в файл на буферизированную запись (то есть пишется в буфер и при накоплении идет сброс буфера в файл), то ускорение было примерно в 10 тыс раз (или даже в 100 тыс раз, не помню точно)

Файл как и сеть — очень долгие операции ввода/вывода (I/O), когда вы прокручиваете тысячи записей, ловите исключения и пишите в синхронном варианте (если не используете асинхронные фреймворки и делаете по классике в пхп) в лог, то это оооочень долгие операции относительно создания объекта исключения

Напомню: на локальном компе я создал 15000 объектов исключений и накладные расходы были на все них меньше сотой секунды (добавь я запись в файл каждого, то прилетели :) а если еще раздуть стек-трейс и эти портянки в логи писать, так вообще

[Максим Федоров]

HellWalk,

итого попробуйте

try {
    //
} catch (\Throwable $e) {
      // 1. $this->logger->error('Message', ['exception' => $e]);
      // 2. $this->logger->error('Message');
      // 3. return false;
}

Все три варианта разные, все 3 на основе исключений
у всех у трех будет разное время выполнения (от долгого к короткому), последний подразумевает возврат true в секции try

[HellWalk]

Максим Федоров,

А вот это обидно, так как именно я на это указал в своем ответе и тут вам разные люди пытаются просто это разжевать :(

Не важно, потому что в файл ничего не логируется - проверил. Это и логично, потому что все исключения перехватываются на более высоких уровнях.

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

[Максим Федоров]

HellWalk, тут нет загадки скорее всего, а нужен код

я проверил, накладные расходы на 15 000 new Exception
То, что кто-то удивилися или не удивился — не имеет значение, имеет значение график профайлера

[HellWalk]

Максим Федоров,

удивилися или не удивился — не имеет значение, имеет значение график профайлера

А как тебе такое:

walk@home:/var/www/oos-dev/sites/api-purchases$ s app:get-sales-price
Received 2021-11-15 15:39:41
Memory limit: -1
Json size: 892.1 kb
[2021-11-15 15:40:58] Error: {"1":"Product с articleNumber 101206 не найден","2":"Product с articleNumber 605549 не найден","3":"Product с articleNumber 322288 не найден","4":"Product с articleNumber 322288 не найден","5":"Product с articleNumber 322288 не найден","6":"Product с articleNumber 322679 не найден","7":"Product с articleNumber 322679 не найден","8":"Product с articleNumber 101206 не найден","9":"Product с articleNumber 999810 не найден","10":"Product с articleNumber 999810 не найден","11":"Product с articleNumbe...
Общий расход памяти: 10.96 mb
Расход памяти на обработку: 8.67 mb
----------------------------------------->>>
walk@home:/var/www/oos-dev/sites/api-purchases$ XDEBUG_CONFIG=profiler_output_name=sales_price XDEBUG_MODE=profile s app:get-sales-price
Received 2021-11-15 15:41:36
Memory limit: -1
Json size: 892.15 kb
[2021-11-15 15:41:37] Error: {"1":"Product с articleNumber 355212 не найден","2":"Product с articleNumber 605549 не найден","3":"Product с articleNumber 355212 не найден","4":"Product с articleNumber 101206 не найден","5":"Product с articleNumber 101206 не найден","6":"Product с articleNumber 355212 не найден","7":"Product с articleNumber 322288 не найден","8":"Product с articleNumber 322288 не найден","9":"Product с articleNumber 322645 не найден","10":"Product с articleNumber 322288 не найден","11":"Product с articleNumbe...
Общий расход памяти: 10.96 mb
Расход памяти на обработку: 5.52 mb
----------------------------------------->>>

Объем данных одинаковый. Количество записей в логах в базе - тоже. В коде ничего не менялось. А разница по времени...

[Максим Федоров]

HellWalk, я ничего не могу сказать без анализа кода

Время — типичный признак I/O bounded (сеть, ожидание доступа работы с файлом)

Answer 3

[Армянское Радио]

Comments

[HellWalk]

https://github.com/symfony/symfony/blob/5.4/src/Sy...

По вашей логике, если программист бросил исключение в валидации - он плохой программист, т.е. создатели симфони говнокодеры?

[Армянское Радио]

HellWalk, если валидируется один файлик - это не проблема. Если 15к - код от разработчиков Симфонии не пролезет без тюнинга механизма обработки исключений.

Не бывает универсального идеального кода. Из этого не следует, что Симфонию писали плохие разработчики, из этого только следует, что в данной конкретной задаче она не подходит, по крйней виде в том виде, в каком она есть.

Настоятельно рекомендую вам немедленно спилить мушку - прекратить выяснять, кто из разработчиков больше разработчик, а перейти собственно к поиску решения проблемы.

[HellWalk]

Армянское Радио,

Если 15к - код от разработчиков Симфонии не пролезет без тюнинга механизма обработки исключений.

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

На что получаю какие-то камни в свой огород, со словами что я должен сделать... тоже, о чем и написал в вопросе.

[Армянское Радио]

HellWalk, извините, вы сделали не тюнинг, а то, что Барт на доске написывает - заменили исключения на обычный лог.

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

[HellWalk]

Армянское Радио,

извините, вы сделали не тюнинг, а то, что Барт на доске написывает

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

И я опускаю то, что посыл отказа от исключений в принципе, который тут пропагандируют - это плохой подход.

вероятнее всего, форсированно пишется на диск.

Сомневаюсь, но в понедельник проверю.

[galliard]

HellWalk, а ты внимательнее посмотри на код симфони:

if ($constraint->minHeight) {
            if (!ctype_digit((string) $constraint->minHeight)) {
                throw new ConstraintDefinitionException(sprintf('"%s" is not a valid minimum height.', $constraint->minHeight));
            }

            if ($height < $constraint->minHeight) {
                $this->context->buildViolation($constraint->minHeightMessage)
                    ->setParameter('{{ height }}', $height)
                    ->setParameter('{{ min_height }}', $constraint->minHeight)
                    ->setCode(Image::TOO_LOW_ERROR)
                    ->addViolation();

                return;
            }
        }

Тут исключение кидается только в случае неправильного конфигурирования самого валидатора. Такая ошибка вылетит один раз на этапе разработки. А валидация именно входящих данных проверяется if'ом.

[HellWalk]

galliard, да, верно, но и Exception на самом деле не замедляют работу.
Запускал с xdebug profiler - и, внезапно, 15 тысяч exception никак не тормозят обработку.
В общем, там что-то странное.

[Армянское Радио]

HellWalk, Так и какой же компонент системы оказывается в итоге нагружен?

[HellWalk]

Армянское Радио, так как с профайлером все отрабатывает быстро, то чтобы это понять - надо вручную делать какой-то замер времени на разных частях обработки. Это время, и оставил это до лучших времен.

[Армянское Радио]

HellWalk, в atop же можно посмотреть