@AndrewSilin является ли открытой информация, сколько обучающихся на Практикуме нанимает сам Яндекс? Если это открытая информация, то было бы интересно еще узнать, как это происходит: прям во время обучения или в течение нескольких дней после.
Только увидел коментарий. Весь парсер у нас писался руками. Мы используем на макросах С некоторое подобие DSL, чтобы писать было проще. Есть HTTP парсеры, сгенерированные Ragel, но, во-первых, насколько помню, не вся грамматика HTTP может быть выражена таким генератором парсеров. Во-вторых, мы старались изолировать парсер от остального кода (аллокаторов памяти, сетевых структур и HTTP логики), но на практике это получается плохо.
Иными словами, если мы посмотрим не только на сервера, которые могут обрабатывать трафик из Internet типа Nginx, H2O, Varnish, HAproxy, но и "легкие" реализации, в основном предназначенные для микросервисных коммуникаций типа boost::beast, Pistache, libhttpserver или uWebSockets - у всех будут руками написанные парсеры.
Спасибо за статью — давно заняю ваш WAF, но не думал, что есть пробная бесплатная версия!
У меня есть несколько вопросов и буду рад, если ответите:
можете сделать какой-то ликбез относительно ModSecurity? Что ловится регекспами и используются ли они, а что ML?
если используются регекспы, то что внутри: PCRE JIT, Hyperscan, или вообще что-то свое?
можете ли дать какой-то ориентир сколько RPS ваш WAF может обработать на одно ядро CPU в каких-то конфигурациях (например, минимально, 100 регекспов, полная база)?
Причин несколько: отсутсвие копирований, оптимизированная работа с памятью, отсутствие контекст свитчей. Ну и конечно, более новые алгоритмы криптографии тоже дают свой эфект.
найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Go
Совершенно адекватное интервью. Я бы сказал, что позиция, скорее, на tech lead, поскольку нужно "задать" высокий уровень, чем senior. Но я не совсем понял
средний балл по опроснику — 3.3 по шкале 0-9. 3.3, Карл! 3.3 — это, с моей точки зрения, уровень junior. Middle должен набирать, я считаю, 5+. Senior — 8+.
По всей видимости, плохо отработали HR или те, кто просматривал резюме — нужно было более серьезных людей пропускать на собеседование.
Возможно, и проблема с деньгами — люди, кто могут показать 8+ просто не особо шли. Впрочем, их и очевидно просто мало.
Считать среднее вообще не имеет смысла. Это нормальная статистика, что, чтобы нанять одного разработчика нужно провести около 10 собеседований. И это при хорошем фильтре резюме, как для mid, так и senior. Соответственно, да: 9 из 10 мидов попадают под <5, 9 из 10 сеньоров под <8.
Я имел ввиду, что из C++ программы я могу заинклюдить C хедер и в общем случае (не учитывая, напирмер, использование new идентификаторов в C) это "работает из коробки". Есть интеграция из C++ в C через extern "C". Так или иначе, но С++ наиболее совместим с C. Например, наткнулся на такой пост про использование C хедеров из D: https://atilaoncode.blog/2018/04/09/include-c-headers-in-d-code/ .
Вася на Rust не напишет в 2 раза быстрее, потому что "Вася" — это средний программист, который о Rust только слышал, в бою его не пробовал. Начиная новый проект, мы знаем, что на рынке много C/C++ разработчиков, много наработанных библиотек, инструментариев и просто ответов на StackOverflow.
Новый язык — это для энтузиастов, кто готов вечерами посидеть с багами в новом языке, поучить матчасть и пр. Вот, и выбирайте как скоротать долгий осенний вечер — выучить новый язык или лучше разобраться в архитектуре и компиляторе знакомго языка.
Давайте посмотрим на первый бенчмарк Rust и C. Во-первых, эту программу на Rust, как многие другие для этих бенчмарков, написала команда разработчиков Rust — коментарий из копирайта:
contributed by the Rust Project Developers
Я не могу оценить реализацию самого бенчмарка на Rust, но копирайт заставляет думать, что там сделано хорошо.
Я занимаюсь разработкой высокопроизводительного кода, часто нам нужен именно "чемпионский" код — показать самые высокие на рынке бенчмарки. Для меня очень важна скорость работы кода и иногда мне не хватает C.
В качестве практического примера приведу быстрые парсеры. В моем случае для разработки быстрого HTTP прасера понадобился не только GOTO, которого нет в Rust, но еще и computed labels — это уже compiler specific расширения для C.
Т.е. вот, есть реальная, не такая маленькая, задача, которую C решает лучше Rust. Но я не видел ни одной задачи, которую Rust решает лучше C. Удобство и быстрота разработки — возможно, но не скорость работы.
Если мучительно отлаживать указатели на C, то мы используем C++ с его smart pointers, RAII и пр. (Я могу вспомнить пару плохонаписанных, не наших, C проектов, которые мы переводили на C++ и в наиболее геморойных местах заменяли C указатели на smart pointers). В C++ можно всегда и просто встроить код на C, который будет работать очень быстро: совместимость с C — ключевое свойство C++ для системного программирования. C Rust, как и с D (тоже была такая 'лучшая' альтернатива C++), будут еще телодвижения на совместную компиляцию с C.
А еще видел неплохое, относительно нейтральное, сравнение C и Rust.
Перевод хороший, но оригинальная статья имеет очень странную "отсебятину" в сторону Rust.
Rust в качестве второго языка ядра
Прям очень громкое заявление. Речь идет о драйверах, которые и сейчас на C часто не удовлетворяют стилю кодирования, принятому в ядре. Очень сомнительно, что кто-то будет писать модули для основных подсистем Linux (аллокаторы памяти, СС алгоритмы в сети, LSM модули и пр.) на Rust.
На мой взгляд сканировать журнал событий и по нему собирать статистику — не очень оптимально. Если правильно понял описание ваших скриптов, то в Linux это делается с помощью fail2ban.
Про ветярнные мельницы я не понял. Мы бьемся за быстрый HTTPS. Для нас "нагруженной системой" может быть, как массивный bare metal, так и однопроцессорная VM, которая тоже должна работать быстро. Для нас, как и большинства людей, не очень приемлемо молотить все доступные CPU на 100% даже при простое.
C теорией NAPI и сетевых прерываний я знаком, но за ссылку спасибо :) Вопросов все равно много остается: проборс VF с VM и SR-IOV — это один только из кейсов, а что будет с трафиком между двумя VM на одном хосте? Будет куча VM-EXIT и в perf kvm stat будут EXTERNAL_INTERRUPT.
Поживем, увидим как будут развиваться серверные ARM, но пока у них use cases очень ограничены.
В среднем по больниц, понятно. Я мимоходом смотрел, например, на Marvell ThunderX2, которые до 256 потоков имеют, и как-то не понятно как там с APIC, а что с виртуализацией — тем более. Работал с ними или смотрел подробнее? У Xeon с vAPIC не очень — 4 машины (entry level) взяли и ни у одной не было vAPIC полного, чтобы KVM не воткнула на I/O.
С сетью у нас интересная история. С packet forwarding/filtering на уровнях L2-L4 все понятно — логики мало и она относительно легко скейлится на ядра, DPDK и пр. kernel bypass рулят. У нас же HTTPS прокси и в perf top, как правило, HTTP parser, криптография, различная прикладня логика, например генерация cookie или javascript челленджей, матчинг HTTP заголовков опять же. Т.е. сетевых функций Linux networking мы не видим. Но при, этом без vAPIC в KVM и мы и Nginx "втыкаем" по полной и разница по произволительности 2 раза в лучшем случае.
Кстати, я недавно писал про user-space TCP в приложении для HTTP. У Seastar реализация TCP фейковая (в смысле "fake it before you make it") — просто, чтобы поставить рекодные бенчмарки: очень мало кода и с кучей TODO. F-stack показывает хорошие результаты, но я проверил сделали ли они что-то с известной проблемой хеш таблицей TCP соединений (она же давно была описана CloudFlare), но и в ядре Linux, и FreeBSD, и F-stack реализация все та же и примерно с одним подходом.
Итого, несмотря на отличные бенчмарки и безумное число ядер ARM, если у них нет хорошего APIC — с сетью, и думаю, с дисковым I/O тоже, все будет плохо. Нет поддержики виртуализации (в т.ч. virtual page talbe) — все плохо будет в облаках. И что останется? Числодробилки для ML?.. Возможно, и это ложится в карту NVIDIA.
Но так было раньше. На ассемблере уже давно никто не пишет. Сейчас за программистов всё это делают компиляторы, поэтому никаких сложностей с написанием кода под RISC-процессоры нет.
Вообще-то, пишут. И иногда на CISC асемблере писать проще, чем на C. Посмотрите ядро Linux или более или менее быструю криптобиблитеку (OpenSSL, WolfSSL, Tempesta TLS). Простой пример: как сложить два 128-битных числа (каждое из которых по 2 long'а)? На C вам прийдется делать телодвижения с битом переноса, а на ассеблере у вас уже есть инструкция, которая в старшее 64-битное число добавит перенос со сложения прошлых 64-х битных чисел. Но, с другой стороны, те, кто упирается в бенчмарки, погемороятся с RISC ассемблером.
Я не очень хорошо знаком с ARM, но интересует что у этой архитектуры с virtual APIC? На x86 без vAPIC сеть в виртуалке очень тормозит.
Слышал от знакомых жалобу на другую проблему с APIC на каких-то ARM процессорах: на 8-и ядерном ARM (не знаю точно каком) нельзя было разбросать очереди прерываний с сетевой карты на разные ядра — все прерывания уходили на одно ядро. Как у современных ARM (которые по 128 потоков и выше умеют) дела с APIC?
3000 контактов в месяц — это примерно 17 контактов в час, или не более, чем по 4 минуты на котакт. Что вы успеете понять про компанию и конкретного человека? В реальности — это рассылка шаблона с подстановкой имени человека, в лучшем случае, если у вас будет 2-4 шаблона по категориям ICP. Эта схема работает для покрытия большой аудитории и «встрытия» «маловероятных» лидов, т.е. лидов, не очень из вашего ICP, но по тем или иными причинам, имеющих потребность в вашей услуге/продукте. Конверсия у таких рассылок очень низкая, 1% — уже очень хороший показатель. Немаловажный фактор, что эти 3000 контактов в месяц баланисруют на тонкой грани между B2B продажами и спамом. Здесь ессть вытекающие последствия.
Другая стратегия — это делать всего по несколько контактов в день, но к каждому контакту писать руками сообщение, очень хорошо таргетированное. На разработку одного хорошего лида может тратиться по несколько часов: анализ сайта, поиск контактов, гугление каждого контакта по его статьям/докладам и пр., подготовка текста инвайта почему лиду интересно будет с вами общаться. Можно пользоваться InMail (платная опция за $60/месяц) и там должен быть USP под конкретного человека и его проект. За месяц хорошо, если SDR сделает 100 контактов, но с такими контактами можно войти в очень крупные организации.
Для нас на практике лучше работает комбинация этих подходов: закупка на стороне лидов по первой стратегии и генерация более качественных лидов in-house. Мы очень много пробовали получить вторую стратегию от внешних поставщиков лидов, но это не работает — сторонние компании не будут и не могут действительно глубоко погружаться в ваши продукты и ICP.
P.S. Только прочитал, что автор предоставляет Сервис по привлечению клиентов через Linkedin. Хотя я и написал, что имеет смысл закупать такой сервис на стороне, но допишу, что нужно внимательно смотреть на работу такого поставщика. Как правило, за одним аккаунтом будет один человек, который единолично и будет генерировать эти 3000 контактов, причем, в реальности тартить на каждый из них еще меньше 4 минут. Черевато попаданием в различные spam фильтры и созданием негативного имджа бренда.
У меня не было целью рассказать об утилитах системного администрирования и как-то их сравнить. Я специально в начале доклада (этот пост — это не статья, а транскрипция моего доклада) рассказал о работе Брендана Грегга и дал ссылку на него — у него очень много именно по инструментарию. Цель же доклада: показать как локализовать проблему производительности и почему для этого желательно иметь базовые знания о ядре ОС.
@AndrewSilin является ли открытой информация, сколько обучающихся на Практикуме нанимает сам Яндекс? Если это открытая информация, то было бы интересно еще узнать, как это происходит: прям во время обучения или в течение нескольких дней после.
Только увидел коментарий. Весь парсер у нас писался руками. Мы используем на макросах С некоторое подобие DSL, чтобы писать было проще. Есть HTTP парсеры, сгенерированные Ragel, но, во-первых, насколько помню, не вся грамматика HTTP может быть выражена таким генератором парсеров. Во-вторых, мы старались изолировать парсер от остального кода (аллокаторов памяти, сетевых структур и HTTP логики), но на практике это получается плохо.
Иными словами, если мы посмотрим не только на сервера, которые могут обрабатывать трафик из Internet типа Nginx, H2O, Varnish, HAproxy, но и "легкие" реализации, в основном предназначенные для микросервисных коммуникаций типа boost::beast, Pistache, libhttpserver или uWebSockets - у всех будут руками написанные парсеры.
Спасибо за развернутый ответ!
Спасибо за статью — давно заняю ваш WAF, но не думал, что есть пробная бесплатная версия!
У меня есть несколько вопросов и буду рад, если ответите:
можете сделать какой-то ликбез относительно ModSecurity? Что ловится регекспами и используются ли они, а что ML?
если используются регекспы, то что внутри: PCRE JIT, Hyperscan, или вообще что-то свое?
можете ли дать какой-то ориентир сколько RPS ваш WAF может обработать на одно ядро CPU в каких-то конфигурациях (например, минимально, 100 регекспов, полная база)?
Vultr, например, дает anycast, причем достаточно дешево.
Мы недавно сравнивали Rust с C/C++ в контексте производительности (обусждения на Hacker News https://news.ycombinator.com/item?id=24960108 и Reddit https://www.reddit.com/r/programming/comments/jjtobp/fast_programming_languages_c_c_rust_and_assembly/).
Rust позволяет писать более безопасный код, хотя C++ движется тоже в эту сторону. Интересный доклад на эту тему с CppCon'20 Closing the Gap between Rust and C++ Using Principles of Static Analysis.
Но Rust по своему дизайну делает разработку быстрого кода сложнее (примеры приводил в блоге).
Go для утилит типа ls — вполне, но для ядра ОС, например, очевидно — нет.
Пропустил я этот тред. Конкретно на вопрос
про TLS handshakes мы с JackMonterey отвечали в https://netdevconf.info/0x14/session.html?talk-performance-study-of-kernel-TLS-handshakes (видео https://www.youtube.com/watch?v=THJ6zC1V10c). При том, что мы еще не закончили оптимизацию математики, уже виден прирост производительности на 80% относительно OpenSSL/Nginx, latency может быть до 4 раз меньше. В моей демо на Security Weekly https://www.youtube.com/watch?v=IxLB3aUAECk хендшейки на виртаулке в несколько раз становились быстрее.
Причин несколько: отсутсвие копирований, оптимизированная работа с памятью, отсутствие контекст свитчей. Ну и конечно, более новые алгоритмы криптографии тоже дают свой эфект.
Более подробно будем еще рассказывать на следующем HighLoad++ https://www.highload.ru/moscow/2020/abstracts/7085 и Linux Conf Au'21 https://linux.conf.au/schedule/presentation/64/
Для позиции
Совершенно адекватное интервью. Я бы сказал, что позиция, скорее, на tech lead, поскольку нужно "задать" высокий уровень, чем senior. Но я не совсем понял
По всей видимости, плохо отработали HR или те, кто просматривал резюме — нужно было более серьезных людей пропускать на собеседование.
Возможно, и проблема с деньгами — люди, кто могут показать 8+ просто не особо шли. Впрочем, их и очевидно просто мало.
Считать среднее вообще не имеет смысла. Это нормальная статистика, что, чтобы нанять одного разработчика нужно провести около 10 собеседований. И это при хорошем фильтре резюме, как для mid, так и senior. Соответственно, да: 9 из 10 мидов попадают под <5, 9 из 10 сеньоров под <8.
Привет!
Это правда :) Зря я написал слово "треш".
Я имел ввиду, что из C++ программы я могу заинклюдить C хедер и в общем случае (не учитывая, напирмер, использование
newидентификаторов в C) это "работает из коробки". Есть интеграция из C++ в C черезextern "C". Так или иначе, но С++ наиболее совместим с C. Например, наткнулся на такой пост про использование C хедеров из D: https://atilaoncode.blog/2018/04/09/include-c-headers-in-d-code/ .Вася на Rust не напишет в 2 раза быстрее, потому что "Вася" — это средний программист, который о Rust только слышал, в бою его не пробовал. Начиная новый проект, мы знаем, что на рынке много C/C++ разработчиков, много наработанных библиотек, инструментариев и просто ответов на StackOverflow.
Новый язык — это для энтузиастов, кто готов вечерами посидеть с багами в новом языке, поучить матчасть и пр. Вот, и выбирайте как скоротать долгий осенний вечер — выучить новый язык или лучше разобраться в архитектуре и компиляторе знакомго языка.
Давайте посмотрим на первый бенчмарк Rust и C. Во-первых, эту программу на Rust, как многие другие для этих бенчмарков, написала команда разработчиков Rust — коментарий из копирайта:
Я не могу оценить реализацию самого бенчмарка на Rust, но копирайт заставляет думать, что там сделано хорошо.
Реализация на С https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gcc-3.html — достаточно короткая реализация на OpenMP и APR, но явно не оптимизировалась вообще.
Я занимаюсь разработкой высокопроизводительного кода, часто нам нужен именно "чемпионский" код — показать самые высокие на рынке бенчмарки. Для меня очень важна скорость работы кода и иногда мне не хватает C.
В качестве практического примера приведу быстрые парсеры. В моем случае для разработки быстрого HTTP прасера понадобился не только
GOTO, которого нет в Rust, но еще и computed labels — это уже compiler specific расширения для C.Т.е. вот, есть реальная, не такая маленькая, задача, которую C решает лучше Rust. Но я не видел ни одной задачи, которую Rust решает лучше C. Удобство и быстрота разработки — возможно, но не скорость работы.
Если мучительно отлаживать указатели на C, то мы используем C++ с его smart pointers, RAII и пр. (Я могу вспомнить пару плохонаписанных, не наших, C проектов, которые мы переводили на C++ и в наиболее геморойных местах заменяли C указатели на smart pointers). В C++ можно всегда и просто встроить код на C, который будет работать очень быстро: совместимость с C — ключевое свойство C++ для системного программирования. C Rust, как и с D (тоже была такая 'лучшая' альтернатива C++), будут еще телодвижения на совместную компиляцию с C.
А еще видел неплохое, относительно нейтральное, сравнение C и Rust.
Перевод хороший, но оригинальная статья имеет очень странную "отсебятину" в сторону Rust.
Прям очень громкое заявление. Речь идет о драйверах, которые и сейчас на C часто не удовлетворяют стилю кодирования, принятому в ядре. Очень сомнительно, что кто-то будет писать модули для основных подсистем Linux (аллокаторы памяти, СС алгоритмы в сети, LSM модули и пр.) на Rust.
Чтобы было больше треша, на Netdev предлагали и Lua в ядре https://lwn.net/Articles/830154/
На мой взгляд сканировать журнал событий и по нему собирать статистику — не очень оптимально. Если правильно понял описание ваших скриптов, то в Linux это делается с помощью fail2ban.
В Tempesta FW есть специальное правило для блокировки переборщиков паролей. Например,
заблокирует IP клиента, если его запросы сгенерировали 10 ответов с кодами 401 или 403 за 3 секунды.
Так же, таки блокировки можно делать и на ModSecurity.
Про ветярнные мельницы я не понял. Мы бьемся за быстрый HTTPS. Для нас "нагруженной системой" может быть, как массивный bare metal, так и однопроцессорная VM, которая тоже должна работать быстро. Для нас, как и большинства людей, не очень приемлемо молотить все доступные CPU на 100% даже при простое.
C теорией NAPI и сетевых прерываний я знаком, но за ссылку спасибо :) Вопросов все равно много остается: проборс VF с VM и SR-IOV — это один только из кейсов, а что будет с трафиком между двумя VM на одном хосте? Будет куча VM-EXIT и в
perf kvm statбудутEXTERNAL_INTERRUPT.Поживем, увидим как будут развиваться серверные ARM, но пока у них use cases очень ограничены.
Привет!
В среднем по больниц, понятно. Я мимоходом смотрел, например, на Marvell ThunderX2, которые до 256 потоков имеют, и как-то не понятно как там с APIC, а что с виртуализацией — тем более. Работал с ними или смотрел подробнее? У Xeon с vAPIC не очень — 4 машины (entry level) взяли и ни у одной не было vAPIC полного, чтобы KVM не воткнула на I/O.
С сетью у нас интересная история. С packet forwarding/filtering на уровнях L2-L4 все понятно — логики мало и она относительно легко скейлится на ядра, DPDK и пр. kernel bypass рулят. У нас же HTTPS прокси и в perf top, как правило, HTTP parser, криптография, различная прикладня логика, например генерация cookie или javascript челленджей, матчинг HTTP заголовков опять же. Т.е. сетевых функций Linux networking мы не видим. Но при, этом без vAPIC в KVM и мы и Nginx "втыкаем" по полной и разница по произволительности 2 раза в лучшем случае.
Кстати, я недавно писал про user-space TCP в приложении для HTTP. У Seastar реализация TCP фейковая (в смысле "fake it before you make it") — просто, чтобы поставить рекодные бенчмарки: очень мало кода и с кучей TODO. F-stack показывает хорошие результаты, но я проверил сделали ли они что-то с известной проблемой хеш таблицей TCP соединений (она же давно была описана CloudFlare), но и в ядре Linux, и FreeBSD, и F-stack реализация все та же и примерно с одним подходом.
Итого, несмотря на отличные бенчмарки и безумное число ядер ARM, если у них нет хорошего APIC — с сетью, и думаю, с дисковым I/O тоже, все будет плохо. Нет поддержики виртуализации (в т.ч. virtual page talbe) — все плохо будет в облаках. И что останется? Числодробилки для ML?.. Возможно, и это ложится в карту NVIDIA.
Вообще-то, пишут. И иногда на CISC асемблере писать проще, чем на C. Посмотрите ядро Linux или более или менее быструю криптобиблитеку (OpenSSL, WolfSSL, Tempesta TLS). Простой пример: как сложить два 128-битных числа (каждое из которых по 2 long'а)? На C вам прийдется делать телодвижения с битом переноса, а на ассеблере у вас уже есть инструкция, которая в старшее 64-битное число добавит перенос со сложения прошлых 64-х битных чисел. Но, с другой стороны, те, кто упирается в бенчмарки, погемороятся с RISC ассемблером.
Я не очень хорошо знаком с ARM, но интересует что у этой архитектуры с virtual APIC? На x86 без vAPIC сеть в виртуалке очень тормозит.
Слышал от знакомых жалобу на другую проблему с APIC на каких-то ARM процессорах: на 8-и ядерном ARM (не знаю точно каком) нельзя было разбросать очереди прерываний с сетевой карты на разные ядра — все прерывания уходили на одно ядро. Как у современных ARM (которые по 128 потоков и выше умеют) дела с APIC?
Другая стратегия — это делать всего по несколько контактов в день, но к каждому контакту писать руками сообщение, очень хорошо таргетированное. На разработку одного хорошего лида может тратиться по несколько часов: анализ сайта, поиск контактов, гугление каждого контакта по его статьям/докладам и пр., подготовка текста инвайта почему лиду интересно будет с вами общаться. Можно пользоваться InMail (платная опция за $60/месяц) и там должен быть USP под конкретного человека и его проект. За месяц хорошо, если SDR сделает 100 контактов, но с такими контактами можно войти в очень крупные организации.
Для нас на практике лучше работает комбинация этих подходов: закупка на стороне лидов по первой стратегии и генерация более качественных лидов in-house. Мы очень много пробовали получить вторую стратегию от внешних поставщиков лидов, но это не работает — сторонние компании не будут и не могут действительно глубоко погружаться в ваши продукты и ICP.
P.S. Только прочитал, что автор предоставляет Сервис по привлечению клиентов через Linkedin. Хотя я и написал, что имеет смысл закупать такой сервис на стороне, но допишу, что нужно внимательно смотреть на работу такого поставщика. Как правило, за одним аккаунтом будет один человек, который единолично и будет генерировать эти 3000 контактов, причем, в реальности тартить на каждый из них еще меньше 4 минут. Черевато попаданием в различные spam фильтры и созданием негативного имджа бренда.