Производительность BASH и подобных оболочек

Доброго времени суток уважаемые!

Недавно встала необходимость написать пару дюжин скриптов обработки вывода программ (Linux). Иначе говоря, "написать несколько обработчиков лог-файлов в режиме онлайн". Основная суть происходящего - программы что дают на STDOUT, мы это считываем, обрабатываем (разбираем), и результаты пишем в базу, отсылаем на почту и т.д.

По наитию, исходя из тех соображений, что для разбора вывода не редко нужно использовать регулярки, а в арсенале Linux'а есть отличный набор бинарных (т.е. не скриптовых) программ для обработки в т.ч. регулярных выражений (sed, awk, tr, grep и т.д.) и как мне виделось - такая связка должна была работать быстрее, чем скриптовые языки (в данном случае, речь идёт о знакомых мне Python3 и PHP7). Но в какой-то момент, я упёрся в необходимость формировать выходные данные (для отправки) в формате JSON или хотя бы XML и решил попробовать для этих целей другие варианты (PHP7 и/или Python3, вместо BASH + sed/awk/tr/grep и т.д.).

Даже "на глаз", скорость обработки увеличилась раза в 2-3... Подскажите пожалуйста, с чем это связанно? То есть, меня интересует, связано ли это с моим недостаточным уровнем владения BASH'ем в связке с другими программами, или такой подход действительно может быть медленнее?

Отдельно хотелось бы узнать, можно ли (и если можно то как?) "малой кровью" формировать в BASH'е выходные данные в формате JSON и/или XML? Для "полной чистоты" эксперимента?

Спасибо!

0

Сообщение от wolfalone связано ли это с моим недостаточным уровнем владения BASH'ем в связке с другими программами, или такой подход действительно может быть медленнее?

Мы не видели Ваших программ, то как можно делать вывод об этом?

Сообщение от wolfalone BASH'е выходные данные в формате JSON и/или XML

обрабатывают специализированными парсерами, типа xmlstarlet, html-xml-utils и пр.

0

Сообщение от Marinero Мы не видели Ваших программ, то как можно делать вывод об этом?

В основном, это всякий примитив на подобии и тому подобное, но вывод (входные данные) иногда бывают довольно значительного объёма, например access-log Apache'а за неделю (исключительно в роли примера).

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

P.S. Я понимаю, что дать 100%-но точный ответ на данный вопрос нельзя, в виду отсутствия точных примеров, результатов тестов и так далее. Но, возможно кто-то обладает информацией касательно сравнительного тестирования производительности BASH'a + unix tools против "классических ЯП" (описанных выше)? С "классическими" ЯП мне безусловно удобнее работать, и вроде бы как (в этом я пока не уверен) они делают подобную работу быстрее и в принципе, справляются с задачей. Но, я готов пожертвовать удобством в замен на производительность, так как объём данных в данный момент не велик - килобайты/мегабайты и разница измеряется секундами (в общей сложности), но в конечно счёте данных могут быть гигабайты, а из секунд будут складываться минуты и часы...

BASH изначально выбрал по той причине, что "он уже есть" в системе (он и стандартные *nix-утилиты, практически в любой системе) и ничего ставить не нужно, а так же по причинам описанным в предыдущем сообщении (относительно теории производительности операций обработки текста).

0

Сообщение от wolfalone всякий примитив

Для подобных задач на первое место выходит удобство написания, т.к. мощности современных устройств практичски нивелируют разницу в скорости обработки. Преимущество баш в возможности написать минимальный код, зачастую в 1-2 строки. Если приходится писать что-то более крупное — ЯП удобнее.

Сообщение от wolfalone уже есть" в системе

Perl / Python3 тоже обычно есть в Линуксах…

1

Сообщение от Marinero Perl / Python3 тоже обычно есть в Линуксах…

Тут полностью согласен, но у меня ещё фигирурет PHP, которого почти никогда нет в системе по умолчанию, а c Perl'ом я знаком весьма посредственно, по этому не могу оценить его возможность и производительность, даже примерно.

Ещё раз подумал, всё взвесил, и пожалуй да, остановлюсь на каком-то ЯП, в виду удобства и целостности карты в конечно счёте. Благодарю за помощь!

0

Зачем гадать, кто быстрее, если можно не гадать,
а попробовать разместить одну и ту же задачу на
веткaх bash, python, perl, go, haskell etc
и потом сравнить результат.

(ps: php в этом списке будет лишний )

0

Ради скорости — может, рискнуть на си написать? 21st Century C — такая смачная книга, возникает желание всё писать на си. А если бы вы знали Common Lisp, наверно, написали бы на нём.

0

Сообщение от volodin661 Зачем гадать, кто быстрее, если можно не гадать, а попробовать разместить одну и ту же задачу на веткaх bash, python, perl, go, haskell etc и потом сравнить результат.

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

Сообщение от volodin661 (ps: php в этом списке будет лишний )

Возможно, но на машине, на которой всё это работает в данный момент - PHP7.x уже есть, ну и по моим "замерам", от Python3 (который на этой машине тоже есть) конкретно в этой задаче он не особо отстаёт.

Добавлено через 3 минуты

Сообщение от helter Ради скорости — может, рискнуть на си написать? 21st Century C — такая смачная книга, возникает желание всё писать на си. А если бы вы знали Common Lisp, наверно, написали бы на нём.

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

0

Сообщение от wolfalone Может быть, "потом", когда уже будет больше ясности в потребностях задачи.

Разумно — кроме прочего, будет работающий прототип.

0

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

0

Сообщение от volodin661 и больше всего похоже на то, что хочешь попросить написать скрипты вместо тебя, но стесняешься.

На самом деле нет, по нескольким причинам:
1. Я уже отметил вопрос решенным
2. Я крайне редко чего-то стесняюсь, и сейчас не тот случай...
3. Мне казалось, что с задачей парсинга логов (или подобного текста) сталкивалось довольно большое кол-во людей (чисто гипотетически) и наверняка кто-то уже замерял производительность разных решений (но, видимо таких людей не так много, как я думал)
4. С учётом количества вариаций текста (логов), просить кого-то "написать за меня" нужно было бы не на форуме, а как минимум на фрилансе, и приложить к заданию чёткое ТЗ (это было бы гораздо быстрее, дешевле [из расчёта кол-ва потраченного времени на условную единицу результата], и надёжнее)
5. Я не имею морального права публиковать логи в открытом доступе, тем более - в таком количестве... что бы кто-то "писал за меня", даже на фрилансе, не говоря уже о форуме...

0

Сообщение от wolfalone Даже "на глаз", скорость обработки увеличилась раза в 2-3... Подскажите пожалуйста, с чем это связанно?

Связано это с тем, что каждый раз Ваш bash запускает отдельную программу для обработки к-нибудь регулярного выражение. Т.е. считывает ее с медленного жесткого диска, отправляет в ОЗУ и только потом запускает.
Вам тут дали хороший совет: воспользуйтесь Perl. Он создавался именно для этих задач -- для разбора большого количества текста. Загрузите модуль, который нужен для пре- или пост-обработки. И все будет выполнено очень быстро и качественно.

Можно конечно весь код и в ОЗУ записать. И запускать оттуда. Да и сами файлы в ОЗУ запихнуть, если места хватит. Тогда будет существенно быстрее. Сделать это сложно, но возможно. Как? Говорить не буду. Намекну -- смотрите в сторону динамических библиотек.

1

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

Спасибо! Не понимаю, как я сам ежедневно сталкиваясь с "проблемой CGI" до этого не додумался... За рекомендацию касательно Perl'а отдельное спасибо, обязательно попробую, хотя уже лет 10+ на нем ничего не писал... пока удалось добиться приемлемой производительности на PHP/Python, но раз уже 2-й раз Perl попал в список рекомендованных, думаю стоит его попробовать (попробовать вспомнить )

0

Сообщение от wolfalone но раз уже 2-й раз Perl попал в список рекомендованных, думаю стоит его попробовать

просто это настолько очевидно, что все стесняются сказать вслух.
Некрасиво подозревать, когда вполне уверен (c)

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

1