Парсинг логов в 230 раз быстрее на Rust

Сказ о том, как люди открывают для себя разницу между компилируемыми и интерпретируемыми языками программирования.

Что Rust быстрый - это и так понятно, главная мораль - что Spark говнина сраная и создан создавать проблемы, а не решать.

Вся соль в финале, прям как в Breaking Bad

Всё будет лучше и быстрее на Rust. Надо только переписать ;)

С чего переписывал-то? С пистончика?

Ну и пусть себе открывают, всем хорошо же

Особо понравилось, что на кластере из 100 воркеров оно работало где-то в 5.3 раза быстрее, чем один локальный процесс — остальное Spark в себя сожрал.

Even on my super-fast laptop, my prototype script would take more than 16 hours to parse 24 hours worth of logs.

Python for Spark, running directly against the S3 bucket of logs. With 100 parallel workers, it took 3 wall-clock hours to parse a full day worth of logs and consolidate the results.

my prototype script would take more than 16 hours to parse 24 hours worth of logs.

Ты смотри, даже в реалтайм уложился

The first thing I learned about profiling programs in Rust is that you have to do it with compiler optimizations turned on. Which I was not doing.

Типичная вебмакака.

Лучше обесни, какой упорок придумал debug-билд по дефолту.

Тоже мне проблема.

То-то все на этом спотыкаются.

Он мог бы с таким же успехом переписать на жабаскрипт, так что нет. Он просто эпичный долбан.

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

По ссылке не ходил, но бред.

То есть у js та же производительность, что и у раста? Ну-ну.

Я ж давал ссылку на порт zlib сто раз уже. Чего нукать-то, бери бенчмарки и запускай. Там конечно вагон нюансов, но не «ужас-ужас»

кто не ходил читать, рекомендую таки сходить.

и все равно, rust ещё сыроват.

С чего переписывал-то? С пистончика?

ruby > python > rust > [rust with optimizations and threading]

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

ruby > python > rust > [rust with optimizations and threading]

А, так вот в чем дело.
Еще бы статью написали bash -> с

В тепличных условиях и джава быстрее Си. Но в реальном мире JS - тормоз.

ну перепиши на с или go - думаю эффект будет тот же

в 230 раз быстрее на Rust

чем на ....

И ты конечно можешь привести ссылки на реальные проекты, которые доказывают твои слова :)

Все, кто не прочитал брошюру из 10 страниц про cargo.

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

разница может быть скорей от использования разных фреймворков. Типа, в питоне ты юзал однопоток, переписал на жабу - оно ускорилось. Или взял программу на C++ с кучей визиторов, переписал на Хашкель с паттерн-матчингом - и оно фигак и быстрее. Но это не достоинство языка как такового.

Чтобы быстро парсить логи они должны быть бинарными. Лёня давно об этом говорит.

Зачем их вообще парсить, вместо того чтобы сразу например всё загонять в бд.

Подсказка: связка find, xargs и mawk сделает ваш парсинг со скоростью I/O и без использования памяти.

Грепнуть 500гб текста это не биг дата.

компилируется быстрей, насколько я понимаю

Компилируется наверное да, быстрее. А вот линкуется это ппц. Вот тебе пример - релизный билд llvm у меня линкуется пару минут и я могу это делать в 6 потоков, а дебажный линкуется минут 20 и максимум 3 потока, иначе не укладывается в 16 гигов оперативы и к линкеру приходит oom killer.

Ссылка мертвая

Подожди, сейчас логи допарсятся и заработает.

Суждение не относится к вам лично.

Как-то знакомый программист говорит мне с восторгом:
«Представляешь, раньше программа производила расчет за 30 минут.
Немножко подправил алгоритм и теперь она выполняет расчет за полминуты ..»

То есть оптимизатор в компиляторах статически-типизированных языков не может делать больше предположений и компилировать меньше рантайм-проверок?

В сферическом вакууме и Си, и JS, и Java, и еще куча всего скомпилируют один исходник в примерно один и тот же машинный код.

/fixed

А еще нужно найти «один и тот же исходник».

Смешно, но я реально с этим в процессе работы столкнулся. Сокомандник не хотел интегрировать компоненту, которую я переписал на раст, так как она была слишком медленная (медленнее кода на го в 10 раз).

В конце концов я понял что он просто компилировал в дебаге.

ripgrep

Я с полюсов перекатился, поэтому таких проблем не было.

Perhaps surprisingly, one of the most challenging things about operating RubyGems.org is the logs. Unlike most Rails applications, RubyGems sees between 4,000 and 25,000 requests per second, all day long, every single day. As you can probably imagine, this creates… a lot of logs. A single day of request logs is usually around 500 gigabytes on disk. We’ve tried some hosted logging products, but at our volume they can typically only offer us a retention measured in hours.

About a year ago, the only thing I could think of to do with the full log firehose was to run it through gzip -9 and then drop it in S3. With gzip, the files shrink by about 92%, and with S3’s “infrequent access” and “less duplication” tiers, it’s actually affordable to keep those logs in a bucket: each month worth of logs costs about $3.50 per month to store.

Buried in those logs, there are a bunch of stats that I’m super interested in: what versions of Ruby and Bundler are actively using RubyGems.org, or per-version and per-day gem download counts. Unfortunately, gzipped JSON streams in S3 are super hard to query for data.

Человек познает мир. Узнал, что сервер с его сайтом про Ruby ежедневно генерирует 500 тонн дерьма гигабайт логов. Сначала он их просто gzip-ал, высушивая до 8% от первоначального объема и сохраняя за $3.50 в месяц. Потом обнаружил, что там оказывается есть интересные вещи, но доставать их их сжатого архива тяжко.

is this… big data?

So every day, we generate about 500 files that are 85MB on disk, and contain about a million streaming JSON objects that take up 1GB when uncompressed. What we want out of those files is incredibly tiny—a few thousand integers, labelled with names and version numbers. For example, “2018-10-25 Bundler 1.16.2 123456”, or “2018-10-25 platform x86_64-darwin17 9876”.

With a full set of those counts, we would be able provide seriously useful information about the state of the whole Ruby ecosystem. It would help gem authors to know what versions of Ruby are important to support, and help everyone using Ruby to know whether or not they are upgrading in pace with the majority of other Ruby devs.

Кое-чего по мелочи захотел извлечь из логов.

Without any real idea of how to get those counts out of S3, I started by writing a proof of concept Ruby script that could parse one of the 500 log files and print out stats from it. It proved that the logs did contain the data I wanted, but it also took a really long time. Even on my super-fast laptop, my prototype script would take more than 16 hours to parse 24 hours worth of logs.

If I was going to make this work, I would need to figure out some way to massively parallelize the work. After setting it aside for a while, I noticed that AWS had just announced Glue, their managed Hadoop cluster that runs Apache Spark scripts.

Напейсал скрипт на Ruby (ну а на чем же ще, хе-хе), но обнаружил, что он на его супермощном ноутбуке парсит 24-часовой лог целых 16 часов. В результате стал играться с параллелизмом на AWS, кластеро-хадупы, Glue и прочее, что придумало человечество для высокопроизводительных параллельных вычислений.

Starting from zero experience with Glue, Hadoop, or Spark, I was able to rewrite my Ruby prototype and extend it to collect more complete statistics in Python for Spark, running directly against the S3 bucket of logs. With 100 parallel workers, it took 3 wall-clock hours to parse a full day worth of logs and consolidate the results.

While 3 realtime hours is pretty great, my script must have been very bad, because it was using 300 cpu-hours per day of logs, an average of 36 minutes per log file. That worked out to almost $1,000 per month, which was too much for Glue to work as a permanent solution.

Полное охадупливание (где-то по дороге уже не на Ruby, а на python) разбора логов обошлось ему в $1000 в месяц и 3 часа работы так и не понял какого количества workers

After shelving the problem again, I thought of it while idly wondering if there was anything that I’d like to use Rust for. I’d heard good things about fast JSON and fast text search in Rust, so it seemed like it might be a good fit.

It turns out serde, the Rust JSON library, is super fast. It tries very hard to not allocate, and it can deserialize the (uncompressed) 1GB of JSON into Rust structs in 2 seconds flat.

Impressed by how fast Rust was at JSON, I searched for “rust parsing” and found nom, a parser combinator library. After a few nights of work, I had a working parser combinator that did what I wanted, and I used it to parse the same log files. Excitingly, it could parse a 1GB logfile in just 3 minutes, which felt like a huge win coming from ~30 minutes in Python on Glue.

и .т.д.

В общем, он обнаружил, что оказывается под Rust есть либы для парсинга логов, с которыми тратится 3 минуты на гигабайт логов. А затем он узнал про наличие опции --release и внезапно скорость парсинга уже стала 8 секунд на 1Гб логов (соответственно час с лишним на 500 Гб.). А потом он вспомнил, что Rust умеет еще и параллелить работу по ядрам процессора.

В результате получилось такое сравнение: на AWS на питоне скорость 8 workers = 4200 записей/секунду. На Rust на его 8-ядерном ноутбуке = 399300.

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

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

Реальнее некуда: https://github.com/RazrFalcon/svgcleaner#cleaning-time

Java головного мозга.

https://github.com/RazrFalcon/resvg#performance

resvg - Rust + C + C++, Batik - java.

PS: да, я стартую java каждый раз, но это проблемы жабы. Если кто-то напишет враппер для java который будет из одного процесса работать - тот молодец.

PSS: и resvg не содержит почти ни каких оптимизаций + дёргает C/C++ либы.

переписать <...> нормально на Си

/0

«Переписать нормально» — это с Си, а не на Си.

имхается мне, что Си таки побыстрее раза в два, чем Rust

Хотя на нем конечно надо уметь писать.

имхается мне, что Си таки побыстрее раза в два, чем Rust

В вакууме — да. А в реальном мире на выразительных языках программы обычно получаются быстрее, потому что в 95% случаев программист выберет не «самый оптимальный» алгоритм или подход, а самый оптимальный из тех, которые можно написать на этом языке, не сойдя с ума.

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

Вот вспомнился Perl середины 2000-x.
Он умел просто супер быстро работать с строками.
Как-то попробывал ради интереса развернуть ведомость расчетных листков с вертикального расположения в горизонтальное.
И о чудо!
На формирование текстового файла, содержащего 1000 расчетных листков, расположенных в ряд ушло менее одной секунды!
Вот это скорость!

Падажжи, так если resvg не поддерживает filter, в чём тогда смысл бенчмарка?

Алсо, если у resvg >80% времени занимает генерация PNG, а у жабы — запуск процесса, то что вообще с чем сравнивается, лол?

Фильтры замедлят работу от силы на 10-20%, а не в десятки раз.

Тем более у batik проблемы с anti-aliasing и text kerning. Так что всё честно.

Алсо, если у resvg >80% времени занимает генерация PNG

И? Как будто batik не генерирует PNG.

Тестируется типичная задача - конвертация svg в png.

https://github.com/RazrFalcon/svgcleaner/blob/master/docs/testing_notes.rst#n...

I know that a performance comparison is not fair since svgo have to restart node.js each time. But I don't know how to prevent it or ignore node.js starting time.

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

Ну так подскажи «how to prevent it or ignore node.js starting time».

А тем более выдавать подобные бенчмарки за настоящие, когда речь идет о прогретом коде.

Кстати, а почему бенчмарки JS (и Java) должны игнорировать время прогрева? Прогрев - родовой порок VM, его нужно учитывать.

То есть вы считаете что svgo в ~100 раз медленнее чисто из-за медленного запуска node.js?

Ну да ладно. Вот чистый матан: https://github.com/RazrFalcon/color-thief-rs

Я запускал js код в Chrome:

About 150x faster that JS version.