Оптимизация

Создать компилятор JS с высокой производительностью означает сделать больше, чем разработать сильно оптимизированный компилятор, например TurboFan, особенно это касается коротких сессий, к примеру, загрузки сайта или инструментов командной строки, когда большая часть работы выполняется до того, как оптимизирующий компилятор получит хотя бы шанс на оптимизацию, не говоря уже о том, чтобы располагать временем на оптимизацию. Как решить эту проблему? К старту курса о Frontend-разработке делимся переводом статьи о Sparkplug свече зажигания под капотом Chrome 91.

Вот почему с 2016 года мы ушли от синтетических бенчмарков, таких как Octane, к измерению реальной производительности и почему старательно работали над производительностью JS вне оптимизирующих компиляторов. Для нас это означало работу над парсером, стримингом [этой поясняющей ссылки в оригинале нет], объектной моделью, конкурентностью, кешированием скомпилированного кода...

Впрочем, повернувшись лицом к улучшению производительности фактического, начального выполнения JS, мы столкнулись с ограничениями процесса оптимизации интерпретатора. Интерпретатор V8 сам по себе быстрый и сильно оптимизированный, но интерпретаторам как таковым свойственны накладные расходы, избавиться от которых мы не можем: например на декодирование байт-кода или диспетчеризацию неотъемлемые части функциональности интерпретатора.

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

Выход из положения Sparkplug: новый неоптимизирующий компилятор JavaScript, который мы выпустили вместе с V8 9.1, он работает между интерпретатором Ignition и компилятором TurboFan.

Быстрый компилятор

Sparkplug создан компилировать быстро. Очень быстро. Настолько, что мы всегда можем компилировать, когда захотим, повышая уровень кода SparkPlug намного агрессивнее кода TurboFan, [подробнее здесь, этой ссылки в оригинале нет].

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

Второй трюк в отличие от большинства компиляторов Sparkplug не генерирует промежуточное представление (IR). Вместо этого Sparkplug компилирует прямо в машинный код за один линейный проход по байт-коду и выдаёт соответствующий выполнению байт-кода машинный код. На самом деле компилятор это switch внутри цикла for, который занят диспетчеризацией, чтобы за каждой инструкцией закрепить генерирующие машинный код функции.

// The Sparkplug compiler (abridged).for (; !iterator.done(); iterator.Advance()) {  VisitSingleBytecode();}

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

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

Совместимые с интерпретатором фреймы

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

Sparkplug это рука мастера, которая ловкими, красивыми движениями упрощает большинство этих задач, то есть он поддерживает совместимые с интерпретатором стековые фреймы. Давайте вернёмся немного назад. При выполнении кода во стековых фреймах хранится состояние функции. Это касается каждого вызова какой-то новой функции: для её локальных переменных создаётся стековый фрейм. Этот стек определяется указателем на фрейм в начале и указателем на стек в конце.

Сейчас около половины читателей закричит: "Диаграмма не имеет смысла, стек направлен в другую сторону!" Ничего страшного, я сделал кнопку: думаю, стек направлен вниз.

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

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

Это основной макет стека для всех типов функций; затем идёт соглашение о передаче аргументов и о том, как в своём фрейме функция хранит значения. В V8 мы имеем соглашение для фреймов JS, что аргументы до вызова функции (включая приёмник) добавляются на стек в обратном порядке, а также о том, что первые несколько слотов стека это вызываемая функция, контекст, с которым она вызывается, и количество передаваемых аргументов. Вот наш стандартный фрейм JS.

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

В случае Ignition соглашение становится более явным. Ignition интерпретатор на основе регистров, это означает, что есть виртуальные регистры (не путайте их с машинными!), которые хранят текущее состояние интерпретатора. включая локальные переменные (объявления var, let, const) и временные значения. Эти регистры содержатся в стековом фрейме интерпретатора, вместе с указателем на выполняемый массив байт-кода и смещением текущего байт-кода в массиве.

Sparkplug намеренно создаёт и поддерживает соответствующий фрейму интерпретатора макет фрейма. Всякий раз, когда интерпретатор сохраняет значение регистра, SparkPlug также сохраняет его. Делает он это по нескольким причинам:

1. Это упрощает компиляцию Sparkplug; новый компилятор может просто отражать поведение интерпретатора без необходимости сохранять какое-либо отображение из регистров интерпретатора в состояние Sparkplug.

2. Поскольку компилятор байт-кода выполнил тяжёлую работу по распределению регистров, такой подход ускоряет компиляцию.

3. Это делает интеграцию с остальной частью системы почти тривиальной; отладчик, профайлер, раскручивание стека исключений, вывод трассировки все эти операции идут по стеку, чтобы узнать, каков текущий стек выполняемых функций, и все эти операции продолжают работать со Sparkplug почти без изменений, потому всё, что касается их, они получают из фрейма интерпретатора.

4. Тривиальной становится и замена на стеке (OSR). Замена на стеке это когда выполняемая функция заменяется в процессе выполнения; сейчас это происходит, когда интерпретированная функция находится в горячем цикле (в это время она поднимается до оптимизированного кода этого цикла) и где оптимизированный код деоптимизируется (когда он опускается и продолжает выполнение функции в интерпретаторе), любая работающая в интерпретаторе логика замены на стеке будет работать и для Sparkplug. Даже лучше: мы можем взаимозаменять код интерпретатора и SparkPlug почти без накладных расходов на переход фреймов.

Мы немного изменили стековый фрейм интерпретатора: во время выполнения кода Sparkplug не поддерживается актуальная позиция смещения. Вместо этого мы храним двустороннее отображение из диапазона адресов кода Sparkplug к соответствующему смещению. Для декодирования такое сопоставление относительно просто, поскольку код Sparklpug получается линейным проходом через байт-код. Всякий раз, когда стековый фрейм хочет узнать "смещение байт-кода" для фрейма Sparkplug, мы смотрим на текущую выполняемую инструкцию в отображении и возвращаем связанное смещение байт-кода. Аналогично, когда Sparkplug нужно узнать OSR из интерпретатора, мы смотрим на байт-код в смещении и перемещаемся к соответствующей инструкции Sparkplug.

Вы можете заметить, что теперь у нас есть неиспользуемый слот фрейма, где должно быть смещение байт-кода; избавиться от него мы не можем, поскольку хотим сохранить оставшуюся часть стека неизменной. Мы перепрофилируем этот слот стека, чтобы вместо него кешировать "вектор обратной связи" для текущей выполняющейся функции; это вектор, хранящий данные о форме объекта, и он должен быть загружен для большинства операций. Всё, что нам нужно делать, соблюдать осторожность с OSR, чтобы гарантировать, что мы подставляем либо правильное смещение байт-кода, либо правильный вектор обратной связи для этого слота. В итоге стековый фрейм Sparkplug выглядит так:

Полагаемся на встроенный код

На самом деле Sparkplug генерирует очень мало собственного кода. У JS сложная семантика, так что для выполнения даже самых простых операций требуется много кода. Принудительная повторная генерация такого кода при каждой компиляции оказалась бы плохим решениям по нескольким причинам:

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

2. Этот подход увеличил бы потребление памяти кодом Sparkplug.

3. Пришлось бы переписывать кодогенерацию для большого количества функциональности JS, что, вероятно, означало бы и больше ошибок, и большую поверхность атаки.

Поэтому, чтобы сделать грязную работу, вместо повторной генерации кода Sparkplug вызывает встроенные функции, небольшие сниппеты машинного кода, встроенного в двоичный файл. Они либо совпадают с теми, что использует интерпретатор, либо по крайней мере большая часть кода Sparkplug общая с кодом обработчиков интерпретатора. В действительности код Sparkplug это вызовы встроенных двоичных сниппетов и поток управления.

Вы можете подумать: "Ну и какой тогда смысл во всём этом? Разве Sparkplug не выполняет ту же работу, что и интерпретатор?" и во многом будете правы. Во многих отношениях Sparkplug является "просто" сериализацией выполнения интерпретатора, вызывая те же встроенные двоичные сниппеты и поддерживая тот же стековый фрейм. Тем не менее оно того стоит, потому что Sparkplug удаляет (или, точнее, предварительно компилирует) те самые неустранимые накладные расходы интерпретатора, такие как декодирование операндов и диспетчеризация следующего байт-кода.

Оказалось, что интерпретация эффективнее множества оптимизаций уровня центрального процессора: статические операнды динамически читаются из памяти интерпретатором, вынуждая процессор делать предположения о том, какими могут быть значения. Диспетчеризация к следующей инструкции байт-кода для сохранения производительности требует успешного прогнозирования ветви выполнения, и, даже если предположения и прогнозы верны, по-прежнему нужно выполнять декодирование и диспетчеризацию кода, а также занимать драгоценное пространство различных буферов и кешей. ЦП сам по себе эффективный интерпретатор, хотя он применяется к машинному коду. С этой точки зрения Sparkplug транспилятор из байт-кода Ignition в байт-код центрального процессора, перемещающий выполнение в "эмуляторе" к "нативному" выполнению.

Производительность

Так как же Sparkplug работает на практике? Мы выполнили несколько бенчмарков Chrome на наших ботах для замера производительности со Sparkplug и без него. Спойлер: мы очень довольны.

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

Speedometer

Speedometer это тест, который пытается эмулировать реально работающий фреймворк, создавая веб-приложение для отслеживания списка задач с использованием нескольких популярных фреймворков и проводя стресс-тестирование производительности этого приложения добавлением и удалением задач. Мы обнаружили, что это отличное отражение поведения загрузки и взаимодействия в реальном мире, и мы неоднократно обнаруживали, что улучшения в спидометре отражаются на наших реальных показателях. Со Sparkplug оценка Speedometer улучшается на 510 %, в зависимости от бота.

Обзор бенчмарка

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

На этих тестах мы решили посмотреть метрику V8 Main-Thread Thread, измеряющую общее проведённое в V8 время (включая компиляцию и выполнение), в основном потоке (то есть исключая стриминговый парсинг или фоновую оптимизацию). Это лучший способ увидеть, насколько оправдан Sparkplug, без учёта других источников шума бенчмарка.

Результаты различны и сильно зависят от машины и веб-сайта, но в целом выглядят прекрасно: видно улучшение около 515 %.

Таким образом, V8 имеет новый сверхбыстрый неоптимизирующий компилятор, повышающий производительность V8 в реальных бенчмарках на 515 %. Он уже доступен в V8 v9.1 (укажите опцию --sparkplug), и мы выпустим его вместе с Chrome 91.

Вот что важно заметить: выделившись в отдельную область разработки, фронтенд не ограничивается одним только JavaScript, например есть множество тонкостей в том, каким образом браузер работает с CSS. Вместе с тем оптимизации на уровне браузера не означают, что можно больше не писать аккуратный, компактный и элегантный код. Скорее они означают, что теперь разработчики будут свободнее чувствовать себя, когда захотят написать сложную или тяжёлую функциональность. Если фронтенд вам интересен, вы можете обратить внимание на наш курс Frontend-разработчик, где получите комплексную подготовку, чтобы в дальнейшем писать и поддерживать приложения различного масштаба и уровня сложности.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

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

Но жаловаться на несовершенство этого мира, недостижимость идеалов и тщетность бытия бесполезно. Поэтому перейдём к требованиям. Что хочет очень большая организация?

Чтоб было безопасно. Т.е. чтоб не просто data scientist модный в шортиках из одной американской/китайской/российской компании не мог в рамках своих задач узнать что-то полезное, а даже рядовой админ банка не смог увидеть или унести переписку одного уважаемого человека с другим. Даже в качестве картинки. Даже на свой админский супер-защищённый комп. Следовательно, оно должно быть self-hosted разворачиваемо отдельно и полностью контролируется исключительно теми, кому положено следить и зарплату за это платят. Ещё нужно подключиться к системам, отвечающим за безопасность передаваемого контента. Ещё нужно иметь в руках команды сопровождения все возможные рычаги, чтобы нерадивого пользователя можно было ограничить в желании другому пользователю передавать то, что не положено.

Чтобы было удобно. Сейчас на дворе 2021 год. Но даже закачать справочник пользователей или синтегрить с корпоративной телефонией банка что-то это уже подвиг на грани фантастики. И удивлению моему не было предела тот же slack обладает пользовательским интерфейсом, который физически невозможно объяснить курьеру из доставки подавай ему пользовательский интерфейс ala telegram. И желательно с видео конференциями встроенными. И прям очень нужен голосовой виртуальный ассистент, голосом удобнее. Ещё невозможно объяснить человеку, у которого есть одновременно два телефона, планшет и два компьютера почему ему нужно выбрать, где же можно работать с этим мессенджером, а где остаться без мессенджера. Ну и зачем каждый раз свой номер телефона светить не ясно.

Чтобы было удобно для внутренних коммуникаций. Тут приходят умные люди из разных отделов, департаментов и цельных предприятий и говорят нам возможность узконаправленных рассылок нужна. Таргетированных, как это модно называть. По полу, по городу, по региону, по подразделению, по должности и т.д. И в этот момент все open-source решения для чатов (а их только на github больше 2100 штук) куда-то деваются. Остаются те, кто реально зарабатывает. Но первый пункт не выполняется.

Чтобы развитие продукта помогало бизнесу, а не мешало всем подряд. Удивительно, но с этой точки зрения почти никто не смотрит. Сколько времени сотрудник тратит на поиск телефона в адресной книге где-то там, потом нужно найти телефон, чтобы позвонить и на этом телефоне набрать 11 заветных цифр. И выяснить, например, что номер с ошибкой. Гораздо удобнее нашёл ФИО, посмотрел фото и сразу набрал. Нужно ещё двоих подключить аналогично набрал и добавил. И никакой музыки от абонента, которому кто-то в это время позвонил, портящей всем 114 остальным участникам совещания не только настроение. 2021 на дворе. И чтоб если нужно любой модуль за месяц прикрутить можно было. Ну хорошо, иногда за два

Отсутствие зависимости от вендора и его капризов. Если ты маленькая организация из 50 человек (а по статистике таких ох как много), тебе нужно решение готовое. Даже когда 3000 человек нужно обслужить вопрос даже не стоит идёшь и выбираешь решение. Можно даже покапризничать и тендер объявить. А если у тебя 400 000 сотрудников? А если миллион планируется? Тут и вендоров вечных с хорошим SLA мало, и возможности их контролировать тоже не велики. Или вендор маленький и может случайно помереть при очередном кризисе или принятии закона/уехать ему понадобится всей командой, или вендор большой, но его мало интересуют проблемы конкретного клиента у него самого может быть 40 000 сотрудников и 1000 таких же клиентов по миру.

Казалось бы каждое из этих пяти требований по отдельности легко покрывается тысячами продуктов. Если взять и выкинуть одно тоже есть десятки. А вот всё вместе и сразу можно только самим мучительно делать. Чем и занимаемся. И вас зовём.

Ну и на всякий случай сошлюсь на бородатые требования одного habrовода (http://personeltest.ru/aways/habr.com/ru/post/405887/ - их мы тоже учли и удовлетворили): кроссплатформенность. Чтоб я наконец-то мог сидя на обеде, или в транспорте, или в отпуске кому-то что-то написать с телефона, да и узнать, что мне кто-то написал. И чтоб мой коллега, у которого Линукс, не делал каждый раз печальное лицо при слове чат. заточенный под общение в компаниях. Чтоб у меня был чат, где есть все мои коллеги и только мои коллеги живой активный проект. Чтобы баги, как застывшие в янтаре насекомые, не висели в продукте до конца времён передача файлов. Ну зачем мне заливать эту картинку в общую папку, если я просто могу кинуть её через чат! нормальная синхронизация уведомлений / непрочитанного. Чтобы не как в Скайпе словил сообщение, и потом в течение 24 часов находишь уведомление о нём на каждом своём девайсе.

Продолжение следует.

Представьте ситуацию: вам нужно воспользоваться оплаченным (как вы думаете) сервисом и вдруг оказывается, что он отключен за неуплату. Такая неприятность портит впечатление от бренда, снижая поток прибыли, а внезапно отключенный клиент может не вернуться к сервису. К старту курса о глубоком и машинном обучении делимся переводом о том, как эту проблему решили в Dropbox, где обнаружили, что внедрение ML в обработку клиентских платежей помогает пользователям оставаться довольными и работает лучше внедрённых за 14 лет политик биллинга.

Платежи в Dropbox

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

Всё это происходит за кулисами, когда пользователь Dropbox становится подписчиком. Как только платёж завершается и аккаунт становится платным, также пользователь вступает в платёжный жизненный цикл. Всё это от начала до конца обрабатывается нашей платёжной платформой.

Продление подписки и сбои

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

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

Чтобы определить время платежа от клиента, чья подписка не продлевается, наша платёжная платформа использовала статический набор из примерно 10 различных методов. Так сложилось исторически. Например, мы можем взимать плату с клиента каждые четыре дня, пока платёж не завершится успешно, в течение максимум 28 дней. Если платеж клиента к концу этого срока по-прежнему не выполнен, уровень его учётной записи в Dropbox понижается до бесплатной базовой учётной записи. Конечно, для активных пользователей и команд понижение уровня учётной записи создаёт неприятные впечатления, а для Dropbox недобровольный отток может обернуться упущенной выгодой.

Сбои в оплате могут произойти по ряду причин. Среди них:

• нехватка средств;

• карта с истекшим сроком действия;

• заблокированная карта возможно, сообщается о потере или краже;

• непредсказуемые сбои обработки.

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

Зачем машинное обучение в работе с платежами?

Последние два года, чтобы выяснить, повлияет ли изменение времени оплаты на её успешность, Dropbox проводил A/B-тестирование. Чтобы разработать набор правил о том, когда взимать плату, эти тесты в значительной мере опирались на интуицию и знания людей в предметной области.

Команда платежей должна была вручную разделить пользователей на группы в зависимости от их признаков типа подписки, географического местоположения и т. д., а затем выполнить A/B-тест наших десяти или около того различных жёстко закодированных наборов правил, чтобы определить, какие из них лучше всего подходят для этих признаков. Затем команда платежей сохраняла оптимальный вариант политики для этой группы выставления счетов по умолчанию. Периодически команда проводила повторное тестирование, чтобы узнать, изменились ли для разных пользователей лучшие решения.

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

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

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

Применяя машинное обучение, мы со временем выявили множество улучшений, которые не смогла бы просчитать даже команда ведущих экспертов по платежам:

• устранение ручного вмешательства и сложной логики на основе правил;

• например, Повторяйте каждые X дней или Избегайте попыток оплаты в выходные;

• глобальная оптимизация множества параметров для конкретных сегментов клиентов;

• устойчивость к изменениям клиентов и рынка;

• увеличение общего числа успешных платежей и сокращение времени сбора платежей.

Говоря коротко, применение ML к платежам сделало счастливее и клиентов, и нас.

Как мы сделали это

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

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

Например, мы взяли окно в 8 дней, разделив его на часовые промежутки, так, в общей сложности получилось 192 отрезка времени. Чтобы найти самый протяжённый отрезок времени для попытки обновления, мы использовали наши модели. А также экспериментировали с дневными окнами по 6 и 4 часа.

Сначала эксперименты проводились с оптимизацией каждой попытки независимо. У нас была модель, оптимизирующая решение о том, когда взимать плату с клиента после неудачной первой оплаты. Если рекомендуемая попытка модели также проваливалась, в оставшейся части окна обновления мы по умолчанию возвращались к логике правил. A/B-тесты этой комбинации проводились на отдельных сегментах пользователей в США. Для таргетинга применялся внутренний сервис развёртывания функциональности Stormcrow. Модель стала работать лучше, и мы развернули её.

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

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

Именно эта модель сегодня проходит A/B-тестирование в производстве при помощи Stormcrow со случайным набором команд участников тестирования Dropbox. Результаты пока положительные.

Predict Service

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

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

Чтобы упростить процесс, мы воспользовались созданным и управляемым командой платформы ML сервисом Predict Service, этот сервис управляет инфраструктурой для быстрого создания, развёртывания и масштабирования процессов машинного обучения в Dropbox. Применение Predict Service помогло сократить время ожидания при генерации прогнозов модели с нескольких минут до менее 300 мс для 99 % моделей. Переход на Predict Service также обеспечил возможность легкого масштабирования и чистое разделение двух систем.

С помощью этой системы машинного обучения платёжная платформа собирает все относящиеся к клиенту сигналы, запрашивает обслуживаемую через сервис Predict модель, чтобы получить лучшее время выставления счета, таким образом устраняя все наши разработанные и закодированные за 14 лет A/B-тестирования неоптимальные политики биллинга. Рабочий процесс этой системы построен следующим образом:

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

2. Получение сигналов клиентов. Модуль Predict собирает последние сигналы об использовании и о платежах клиентов, а также информацию о предыдущем сбое. Эти данные сохраняются в Edgestore (основной системе хранения метаданных в Dropbox) ежедневным заданием Airflow Job.

3. Запрос прогноза. Собранные сигналы отправляются в Predict Service через вызов GRPC, который кодирует сигналы во фрейм данных о признаках, а затем отправляет их в модель.

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

5. Логирование результатов прогнозов. Модуль Predict, кроме прочего, логирует результаты прогнозирования модели, а также другую необходимую информацию, которая может использоваться для устранения неполадок и анализа.

6. Расписание следующего платежа. Как только сервис платежей получает наилучшее время списания средств, он учитывает это время при планировании следующей попытки оплаты и сохраняет в Edgestore.

ML-операции

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

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

Бизнес-метрики

• Коэффициент одобрения счетов. Основная метрика, которую нужно улучшить. При каждом продлении подписки в Dropbox все платежи за продление отслеживаются как часть единого счёта. Эта метрика сообщает нам, было ли обновление подписки успешным.

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

Внутренний мониторинг модели

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

• Охват: процент клиентов, получивших рекомендации от модели, в сравнении с подходом фиксированного интервала в 4 дня.

• Количество сделанных моделью прогнозов: количество рекомендаций, которые модель успешно выполнила без каких-либо ошибок.

• Задержка прогнозирования: сколько времени потребовалось модели для составления каждой рекомендации.

Мониторинг инфраструктуры

Наряду с мониторингом и оповещением для платёжной платформы и сервиса Predict мы также отслеживаем следующее, чтобы определить, насколько хорошо работает инфраструктура:

• свежесть и задержки в конвейерах данных признаков;

• доступность и задержка сервиса Predict;

• доступность EdgeStore.

Для мониторинга нашей модели и метрик инфраструктуры мы используем дашборды Grafana и Vortex. Для бизнес-метрик мы используем Superset. Все эти живые метрики и дашборды помогают нам проактивно отслеживать ожидаемое поведение модели, позволяя принимать соответствующие меры, когда оно отклоняется.

Ответственность за мониторинг этих показателей разделена между командой инженеров по платежам и командой прикладного машинного обучения. У нас есть руководства по устранению неисправностей с чёткими путями эскалации, помогающие дежурным инженерам отладить любые проблемы. Поскольку ML был новым для команды инженеров по платежам, мы потратили время на объяснение принципов работы систем и интерпретацию результатов модели. Это помогло двум командам успешно сотрудничать в работе над проектом и обеспечить бесперебойную работу.

Дальнейшие шаги

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

Наша модель, ориентированная на индивидуальных клиентов, в настоящее время внедрена в производство. Модель оптимизации всего цикла обновления сейчас проходит A/B-тестирование. Компания стремится распространить оптимизацию через ML на всех наших клиентов.

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

Здесь мы видим, что в вопросах формальных правил искусственный интеллект может превосходить естественный, а значит, специалисты в области ИИ будут всё более востребованы бизнесом. Если вы не хотите оставаться в стороне от этой бурно развивающийся сферы технологий, то можете обратить внимание на наш курс о машинном и глубоком обучении, где студенты не только создают работающие модели ML и глубокие нейронные сети, но и получают все необходимые специалистам теоретические знания.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Благодаря развитию литий-ионных аккумуляторов в России появилось новое решение для электрических сетей система накопления электрической энергии (СНЭ или СНЭЭ, далее накопитель). Это решение настолько новое и непривычное для сетей, что за каждым реально установленным накопителем стоит разрешение множества нетривиальных задач. Ключ к экономической эффективности использования накопителей поиск и разрешение оптимизационных задач. В статье я расскажу о решении задач, которые помогли снизить стоимость накопителей по трем основным на сегодняшний день применениям.

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

В зависимости от разрешаемых проблем сейчас сформировались три направления применения накопителей в электрических сетях:

• поддержание нормативного уровня напряжения в распределительной перегруженной сети;

• обеспечение надежности энергоснабжения (резервный источник питания);

• замена протяженных незагруженных линий мобильными накопителями.

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

Поддержание нормативного уровня напряжения в распределительной перегруженной сети

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

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

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

Для решения этой задачи требуется:

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

• выбрать наименьший из полученных в каждом узле минимальных накопителей.

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

Более того, для сетей 0.4 кВ нужно учитывать несимметрию нагрузки по фазам. Из-за наличия нулевого провода изменение напряжения в одной фазе влияет на напряжения, а значит и на параметры накопителя, в двух других фазах. Поэтому для каждой из трех фаз подбираются свои параметры накопителя, а начиная со второй итерации расчет корректируется с учетом взаимного влияния режимов фаз друг на друга.

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

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

Решение задачи тестировалось на трех распределительных сетях с количеством опор более 30. По результатам расчетов получились следующие выводы:

• Установка накопителя на первых опорах (5-10 опор ближайших к питающей подстанции) и последних опорах линии не позволяет поднять напряжение до необходимого уровня;

• Разница между минимально необходимыми для обеспечения заданного напряжения накопителями на разных опорах составила до 30% от энергоемкости выбранных для установки накопителей (в рассмотренных сетях это 15 кВтч или 1,5 млн.рублей при цене накопителей 100 тыс.руб/кВтч).

Обеспечение надежности энергоснабжения

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

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

Оценка этих параметров носит вероятностный характер. За вероятность равную единице можно принять время устранения аварии 24 часа и мощность потребителей равную мощности их технологического присоединения. Но такой накопитель будет многократно преразмерен от фактически необходимого. Поэтому для решения этой задачи требуется:

• оценка времени устранения аварий на основании статистических данных в районе установки;

• оценка максимально возможного потребления за время устранения аварий на основании данных почасового учета резервируемых потребителей;

• прогнозирование изменения нагрузки резервируемых потребителей за время эксплуатации накопителя.

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

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

Замена протяженных незагруженных линий мобильными накопителями

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

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

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

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

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

• оценка максимально возможного потребления за время между заменами накопителя, осуществляемая на основании данных почасового учета питаемых потребителей;

• прогнозирование изменения нагрузки питаемы потребителей за время эксплуатации накопителя.

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

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

Введение

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

Однако бывают случаи, когда есть некая база кода, написанного на C#, а возможности быстро переписать всё на Python/C/C++ нет. Тогда встает вопрос как подключить C# к Python?. Для этого была разработана библиотека pythonnet. В этой статье разберем: как запустить C# код из Python и что из этого может получиться.

Реализация

Для сравнения скорости выполнения C# и Python я буду ссылаться на одну из прошлых статей.

Библиотека pythonnet работает с .dll файлами, поэтому весь код необходимо будет преобразовывать в динамически подключаемые библиотеки. Чтобы создать .dll файл из C# необходимо установить visual studio и при создании проекта указать, что проект будет создан для библиотеки классов (я дал название проекту: MyTestCS, в будущем dll файл будет носить такое же название как и проект):

В качестве примера будем использовать магазин из прошлой статьи, который оптимизировали силами самого питона и других языков. Создадим структуру для одного товара на C#:

public struct DataGoods    {        public string name;        public int price;        public string unit;        public DataGoods(string name, int price, string unit)        {            this.name = name;            this.price = price;            this.unit = unit;        }    }

Теперь реализуем класс самого магазина. В нем создадим метод для заполнения магазина товарами:

public class ShopClass    {        public string name;        public List<DataGoods> listGoods;        public ShopClass(string name)        {            this.name = name;this.listGoods = new List<DataGoods>();        }        /// <summary>        /// Метод для создания товаров в магазине        /// </summary>        /// <param name="numberGoods"> Количество объектов в магазине </param>        public void createShopClass(int numberGoods) {            List<DataGoods> lGoods = new List<DataGoods>();            for (int i = 0; i < numberGoods; i++) {                lGoods.Add(new DataGoods("телефон", 20000, "RUB"));                lGoods.Add(new DataGoods("телевизор", 45000, "RUB"));                lGoods.Add(new DataGoods("тостер", 2000, "RUB"));            }            this.listGoods = lGoods;        }   }

После того, как класс был создан, приступим к подключению C# кода к Python проекту. Сначала создадим .dll файл из C# проекта (достаточно нажать команду ctrl+shift+B). В папке bin->debug->netstandart2.0 проекта (путь зависит от того, какие конфигурации среды стоят у вас) появится файл с названием проекта и расширением .dll (именно этот файл будет подключаться к программе на Python).

Далее разберемся с проектом на Python. Необходимо установить библиотеку pythonnet, выполнив команду:

pip install pythonnet

В проекте создадим файл main.py, а также поместим библиотеку MyTestCS.dll в папку с проектом:

Теперь можно подключать библиотеку в main.py, для этого сначала импортируем clr (clr позволяет рассматривать пространства имен CLR как пакеты Python):

import clr

Укажем путь до нашего .dll файла:

pathDLL = os.getcwd() + "\\MyTestCS.dll"

Чтобы подгрузить нужную нам библиотеку необходимо прописать следующий код:

clr.AddReference(pathDLL)

После чего можно импортировать модуль и всё, что в нем содержится. Если напрямую сделать импорт MyTestCS:

import MyTestCSprint(MyTestCS)>>> <module 'MyTestCS'>

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

Создадим экземпляр класса ShopClass и DataGoods через Python и обратимся к полям этих классов.

from MyTestCS import ShopClass, DataGoodsshop = ShopClass("Тест магазин")shop.createShopClass(1)goods = DataGoods("чехол для телефона", 500, "RUB")print(shop.name)>>> Тест магазинprint(shop.listGoods)>>> [<MyTestCS.DataGoods object at 0x000001D04C3FE3C8>, <MyTestCS.DataGoods object at 0x000001D04C3FE438>, <MyTestCS.DataGoods object at 0x000001D04C3FE400>]print(shop.listGoods[1].name, shop.listGoods[1].price, shop.listGoods[1].unit)>>> телевизор 45000 RUBprint(goods.name, goods.price, goods.unit)>>> чехол для телефона 500 RUB

Как итог, получилось вызвать код C# из Python и поработать с классами. Теперь протестируем производительность создания 200*100000 товаров через метод createShopClass:

shop = ShopClass("Тест магазин")s = time.time()shop.createShopClass(200 * 100000)print("СОЗДАНИЕ ТОВАРОВ НА C#:", time.time() - s)>>> СОЗДАНИЕ ТОВАРОВ НА C#: 2.9043374061584473

В прошлой статье время создания такого количества товаров заняло примерно 44 секунды. Использование C# вместо Python позволило ускорить этот процесс примерно в 15 раз, что является очень хорошим результатом.

Проблемы

Однако не может же быть всё настолько хорошо, чтобы броситься переписывать куски кода Python на C#. И это так. Попробуем из Python вручную дополнить товарами магазин:

shop = ShopClass("Тест магазин 1")s = time.time()shop.createShopClass(500000)print("СОЗДАЛИ ТОВАР ЧЕРЕЗ C#:", time.time()-s)>>> СОЗДАЛИ ТОВАР ЧЕРЕЗ C#: 0.07325911521911621shop = ShopClass("Тест магазин 2")s = time.time()for _ in range(500000):        goods1 = DataGoods("телефон", 20000, "RUB")        goods2 = DataGoods("телевизор", 45000, "RUB")        goods3 = DataGoods("тостер", 2000, "RUB")        shop.listGoods.extend([goods1, goods2, goods3])print("СОЗДАЛИ ТОВАР ЧЕРЕЗ PYTHON:", time.time()-s)>>> СОЗДАЛИ ТОВАР ЧЕРЕЗ PYTHON: 5.2899720668792725

И проверим аналогичный код, написанный на Python:

istGoods = []class DataGoods2:        def __init__(self, name, price, unit):            self.name = name            self.price = price            self.unit = units = time.time()for _ in range(500000):        goods1 = DataGoods2("телефон", 20000, "RUB")        goods2 = DataGoods2("телевизор", 45000, "RUB")        goods3 = DataGoods2("тостер", 2000, "RUB")        listGoods.extend([goods1, goods2, goods3])print("СОЗДАЛИ PYTHON ОБЪЕКТ:", time.time()-s)>>> СОЗДАЛИ PYTHON ОБЪЕКТ: 1.2972710132598877

Код чистого питона работает быстрее, чем дополнение объекта, созданного из модуля C#. Это связано с тем, что доступ к объектам, написанным на C#, занимает довольно много времени. Чтобы избежать таких проблем, необходимо писать всю логику работы с классом внутри C# кода, и не выносить эту логику в Python. Изменение скорости выполнения кода будет заметно при подсчете суммы всех товаров. Реализуем функцию подсчета суммы товаров на C# (внутри класса ShopClass):

public long getSumGoods() {    long sumGoods = 0;    foreach (DataGoods goods in this.listGoods) {      sumGoods += goods.price;    }    return sumGoods;}

А также на Python:

shop = ShopClass("Магазин 3")shop.createShopClass(1000000)s = time.time()shop.getSumGoods()print("ВРЕМЯ НА СУММУ ТОВАРОВ C#:", time.time()-s)>>> ВРЕМЯ НА СУММУ ТОВАРОВ C#: 0.0419771671295166sumGoods = 0for goods in shop.listGoods:     sumGoods += goods.priceprint("ВРЕМЯ НА СУММУ ТОВАРОВ PYTHON:", time.time()-s)>>> ВРЕМЯ НА СУММУ ТОВАРОВ PYTHON: 6.205681085586548

Python код выполняется гораздо медленнее, чем внутренние методы C#.

Многопоточность

Так как в C# отсутствует GIL, то мне стало интересно протестировать работу многопоточности в C# и попробовать запустить потоки в C# через Python. Для начала протестируем протестируем создание 3х классов ShopClass последовательно и заполним их 3.000.000 товаров:

public class testShop    {        public void testSpeedNoThread(int count)        {            testShopClass(count);            testShopClass(count);            testShopClass(count);        }        public static void testShopClass(int count)        {            ShopClass shop = new ShopClass("Магазин");            shop.createShopClass(count);        }}

Python код для запуска:

tshop = testShop()s = time.time()tshop.testSpeedNoThread(3000000)print("СОЗДАЕМ ПОСЛЕДОВАТЕЛЬНО 3 МАГАЗИНА:", time.time()-s)>>> СОЗДАЕМ ПОСЛЕДОВАТЕЛЬНО 3 МАГАЗИНА: 2.1849117279052734

Дополним класс testShop для работы с потоками новым методом:

public static void testThread(){    ExThread obj = new ExThread();    Thread thr = new Thread(new ThreadStart(obj.mythread1));    Thread thr2 = new Thread(new ThreadStart(obj.mythread1));    Thread thr3 = new Thread(new ThreadStart(obj.mythread1));    thr.Start();    thr2.Start();    thr3.Start();    thr.Join();    thr2.Join();    thr3.Join();}

И создадим новый вспомогательный класс:

public class ExThread{   public void mythread1()     {         ShopClass shop = new ShopClass("Магазин");         shop.createShopClass(3000000);     }}

Запустим Python код для проверки работы потоков:

s = time.time()tshopThread = testShop()tshopThread.testThread()print("СОЗДАЕМ 3 ПОТОКА C# ДЛЯ 3х МАГАЗИНОВ:", time.time()-s)>>> СОЗДАЕМ 3 ПОТОКА C# ДЛЯ 3х МАГАЗИНОВ: 0.6765928268432617

Вывод

Использование частей кода, написанных на C# в Python возможно, но при таком подходе есть и свои минусы, например, скорость доступа к объектам. Использование pythonnet целесообразно, если имеются какие-то части кода, которые нет возможности переписать на Python, но они требуют подключения к основному проекту на Python.

P.S. есть и другие способы ускорить python, например, написать библиотеку на C/C++ или переписать часть кода на Cython с меньшими проблемами. В данной статье лишь представлена возможность использования C# и Python вместе. Также существует реализация Python для платформы Microsoft.NET под названием IronPython.

Линейный поиск это алгоритм оптимизации, который может использоваться для целевых функций с одной или несколькими переменными. Он предоставляет возможность использовать алгоритм одномерной оптимизации, например поиск методом деления пополам (бисекции) для многомерной целевой функции, работая с линейным поиском для определения оптимального размера шага в каждом измерении от известной точки до оптимума. Мы уже делились переводами Джейсона Браунли, например статьёй о смешанных ансамблях, а в этом учебном руководстве, которое мы перевели к старту курса о машинном и глубоком обучении, рассказывается об основах: вы узнаете, как на Python с помощью линейного поиска выполнить оптимизацию.

Прочитав это руководство, вы узнаете:

• что линейный поиск это алгоритм оптимизации для одномерных и многомерных задач оптимизации;

• что библиотека SciPy предоставляет API выполнения линейного поиска, который требует знания о том, как вычисляется первая производная вашей целевой функции;

• как выполнить линейный поиск для целевой функции и работать с результатом.

Давайте начнём.

Обзор

Этот учебный материал разделён на три части:

1. Что такое линейный поиск?

2. Линейный поиск на Python.

3. Как выполняется линейный поиск? Он состоит из:

a) определения целевой функции;

б) выполнения линейного поиска;

в) работы со сбоями алгоритма.

Что такое линейный поиск?

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

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

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

Один из подходов заключается в применении линейного поиска, выбирающего коэффициент шага, который минимизирует одномерную функцию [...]. Мы можем применить метод одномерной оптимизации по нашему выбору.

Алгоритмы оптимизации, 2019. С. 54.

Альфа коэффициент масштаба для направления, поэтому при поиске учитываются только значения в диапазоне от 0,0 до 1,0. Один шаг линейного поиска решает задачу минимизации, которая минимизирует целевую функцию для текущей позиции в сумме с масштабируемым направлением, то есть:

• Минимизирует objective(position + alpha * direction).

Таким образом, линейный поиск работает в одном измерении за один раз и возвращает расстояние перемещения в выбранном направлении.

Каждая итерация метода линейного поиска вычисляет направление поиска pk, а затем решает, как далеко двигаться в этом направлении.

Численная оптимизация, 2006. С. 30.

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

Решение приблизительно или неточно и в зависимости от формы пространства поиска может не оказаться общим решением. Условия, при которых этот алгоритм подходит, называются условиями Вольфе. Теперь, когда мы знакомы с линейным поиском, давайте посмотрим, как выполнять его на Python.

Линейный поиск на Python

Выполнить линейный поиск на Python можно вручную, с помощью функции line_search(). Она поддерживает одномерную оптимизацию, а также многомерные задачи оптимизации. Эта функция принимает имя целевой функции и имя градиента для целевой функции, а также текущее положение в пространстве поиска и направление движения.

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

...result = line_search(objective, gradient, point, direction)

Функция возвращает кортеж из шести элементов, включая коэффициент масштаба для направления, называемый альфа, и количество выполненных вычислений функций, а также другие значения. Первый элемент в результирующем кортеже содержит альфа. Если поиск не сойдётся, альфа будет иметь значение None.

...# retrieve the alpha value found as part of the line searchalpha = result[0]

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

...# construct the end point of a line searchend = point + alpha * direction

Для задач оптимизации с более чем одной входной переменной, например многомерной оптимизации, функция line_search() вернёт одно альфа-значение для всех измерений. Это значит, функция предполагает, что оптимум равноудалён от начальной точки во всех измерениях, такое ограничение существенно. Теперь, после ознакомления с тем, как в Python выполнять линейный поиск, давайте рассмотрим работающий пример.

Как выполняется линейный поиск?

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

Определение целевой функции

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

• objective(x) = (-5 + x)^2.

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

# objective functiondef objective(x):return (-5.0 + x)**2.0

Первая производная этой функции может быть вычислена аналитически следующим образом:

• gradient(x) = 2 * (-5 + x).

Градиент для каждого входного значения просто указывает наклон к оптимумам в каждой точке. Реализация функции градиента приведена ниже:

# gradient for the objective functiondef gradient(x):return 2.0 * (-5.0 + x)

Можно определить диапазон входных данных для x от -10 до 20 и вычислить целевое значение для каждого входного значения:

...# define ranger_min, r_max = -10.0, 20.0# prepare inputsinputs = arange(r_min, r_max, 0.1)# compute targetstargets = [objective(x) for x in inputs]

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

...# plot inputs vs objectivepyplot.plot(inputs, targets, '-', label='objective')pyplot.legend()pyplot.show()

Связав всё это воедино, получим такой код:

# plot a convex objective functionfrom numpy import arangefrom matplotlib import pyplot # objective functiondef objective(x):return (-5.0 + x)**2.0 # gradient for the objective functiondef gradient(x):return 2.0 * (-5.0 + x) # define ranger_min, r_max = -10.0, 20.0# prepare inputsinputs = arange(r_min, r_max, 0.1)# compute targetstargets = [objective(x) for x in inputs]# plot inputs vs objectivepyplot.plot(inputs, targets, '-', label='objective')pyplot.legend()pyplot.show()

Программа вычисляет входные значения (x) в диапазоне от -10 до 20 и создаёт график, показывающий знакомую U-образную форму параболы. Оптимум функции, по-видимому, находится в точке x=5,0, целевое значение 0,0.

Выполнение линейного поиска

Затем можно выполнить линейный поиск по этой функции. Во-первых, мы должны определить отправную точку поиска и его направление. Здесь воспользуемся начальной точкой x=-5, расстояние от которой до оптимума около 10 единиц. Сделаем большой шаг вправо, в данном случае в 100 единиц (что значительно превышает оптимум), например, в положительном направлении. Напомним, что направление похоже на размер шага и поиск масштабирует размер шага, чтобы найти оптимум:

...# define the starting pointpoint = -5.0# define the direction to movedirection = 100.0# print the initial conditionsprint('start=%.1f, direction=%.1f' % (point, direction))# perform the line searchresult = line_search(objective, gradient, point, direction)

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

...# summarize the resultalpha = result[0]print('Alpha: %.3f' % alpha)print('Function evaluations: %d' % result[1])

Мы можем использовать альфа вместе с нашей начальной точкой и размером шага для вычисления местоположения оптимумов и вычисления целевой функции в этой точке (которая, как мы ожидаем, будет равна 0,0):

...# define objective function minima end = point + alpha * direction# evaluate objective function minimaprint('f(end) = %.3f' % objective(end))

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

...# define ranger_min, r_max = -10.0, 20.0# prepare inputsinputs = arange(r_min, r_max, 0.1)# compute targetstargets = [objective(x) for x in inputs]# plot inputs vs objectivepyplot.plot(inputs, targets, '--', label='objective')# plot start and end of the searchpyplot.plot([point], [objective(point)], 's', color='g')pyplot.plot([end], [objective(end)], 's', color='r')pyplot.legend()pyplot.show()

Ниже приведён полный пример выполнения линейного поиска для выпуклой целевой функции:

# perform a line search on a convex objective functionfrom numpy import arangefrom scipy.optimize import line_searchfrom matplotlib import pyplot # objective functiondef objective(x):return (-5.0 + x)**2.0 # gradient for the objective functiondef gradient(x):return 2.0 * (-5.0 + x) # define the starting pointpoint = -5.0# define the direction to movedirection = 100.0# print the initial conditionsprint('start=%.1f, direction=%.1f' % (point, direction))# perform the line searchresult = line_search(objective, gradient, point, direction)# summarize the resultalpha = result[0]print('Alpha: %.3f' % alpha)print('Function evaluations: %d' % result[1])# define objective function minimaend = point + alpha * direction# evaluate objective function minimaprint('f(end) = f(%.3f) = %.3f' % (end, objective(end)))# define ranger_min, r_max = -10.0, 20.0# prepare inputsinputs = arange(r_min, r_max, 0.1)# compute targetstargets = [objective(x) for x in inputs]# plot inputs vs objectivepyplot.plot(inputs, targets, '--', label='objective')# plot start and end of the searchpyplot.plot([point], [objective(point)], 's', color='g')pyplot.plot([end], [objective(end)], 's', color='r')pyplot.legend()pyplot.show()

Программа-пример сначала сообщает начальную точку и направление. Поиск выполняется, и обнаруживается изменяющая направление для нахождения оптимума значение альфа, в данном случае найденное после трёх вычислений функции 0.1. Точка оптимума находится на отметке 5,0, значение y, как и ожидалось, равно 0,0:

start=-5.0, direction=100.0Alpha: 0.100Function evaluations: 3f(end) = f(5.000) = 0.000

Наконец, создаётся график функции, показывающий зелёную начальную точку и красную цель.

Работа со сбоями алгоритма

Линейный поиск не гарантирует нахождения оптимумов функции. Он может не найти оптимумы, если задано значение направления, недостаточно большое, чтобы охватить их. Например, найти оптимумы будет невозможно, когда направление имеет значение 3. Продемонстрировать это можно на полном примере ниже:

# perform a line search on a convex objective function with a direction that is too smallfrom numpy import arangefrom scipy.optimize import line_searchfrom matplotlib import pyplot # objective functiondef objective(x):return (-5.0 + x)**2.0 # gradient for the objective functiondef gradient(x):return 2.0 * (-5.0 + x) # define the starting pointpoint = -5.0# define the direction to movedirection = 3.0# print the initial conditionsprint('start=%.1f, direction=%.1f' % (point, direction))# perform the line searchresult = line_search(objective, gradient, point, direction)# summarize the resultalpha = result[0]print('Alpha: %.3f' % alpha)# define objective function minimaend = point + alpha * direction# evaluate objective function minimaprint('f(end) = f(%.3f) = %.3f' % (end, objective(end)))

При выполнении примера поиск достигает предела альфа 1,0, что даёт конечную точку от -2 до 49. При f(5) = 0,0 от оптимумов очень далеко:

start=-5.0, direction=3.0Alpha: 1.000f(end) = f(-2.000) = 49.000

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

...# define the starting pointpoint = -5.0# define the direction to movedirection = -3.0

Ожидается, что поиск не сойдётся, поскольку он не может найти какие-либо точки лучше начальной. Полный пример поиска, который не сходится, приведён ниже:

# perform a line search on a convex objective function that does not convergefrom numpy import arangefrom scipy.optimize import line_searchfrom matplotlib import pyplot # objective functiondef objective(x):return (-5.0 + x)**2.0 # gradient for the objective functiondef gradient(x):return 2.0 * (-5.0 + x) # define the starting pointpoint = -5.0# define the direction to movedirection = -3.0# print the initial conditionsprint('start=%.1f, direction=%.1f' % (point, direction))# perform the line searchresult = line_search(objective, gradient, point, direction)# summarize the resultprint('Alpha: %s' % result[0])

Выполнение программы приводит к предупреждению LineSearchWarning, указывающему на то, что поиск, как и ожидалось, не может сойтись. Альфа возвращённое в результате поиска значение равно None:

start=-5.0, direction=-3.0LineSearchWarning: The line search algorithm did not convergewarn('The line search algorithm did not converge', LineSearchWarning)Alpha: None

Дальнейшее чтение

Если вы хотите глубже погрузиться в тему, смотрите этот раздел.

Книги

• Алгоритмы оптимизации, 2019.

• Численная оптимизация, 2006.

API

• Оптимизация и поиск корней (scipy.optimize).

• Оптимизация (scipy.optimize).

• scipy.optimize.line_search API.

Статьи

• Линейный поиск. Википедия.

• Условия Вольфе. Википедия.

Резюме

Из этого руководства вы узнали, как выполнить оптимизацию линейного поиска на Python. В частности, вы узнали:

• что линейный поиск это алгоритм оптимизации для одномерных и многомерных задач оптимизации;

• что библиотека SciPy предоставляет API выполнения линейного поиска, требующий знания о том, как вычисляется первая производная вашей целевой функции;

• как выполнить линейный поиск для целевой функции и работать с его результатом.

Применяемые в машинном обучении методы оптимизации, конечно же, не ограничиваются одним лишь линейным поиском, они многочисленны, разнообразны и у каждого есть свои недостатки и преимущества. Если вы хотите погрузиться в машинное обучение, изучить оптимизацию глубже, но не хотите ограничивать себя областью ML, вы можете обратить внимание на наш курс "Machine Learning и Deep Learning", партнёр которого, компания NVIDIA, не нуждается в представлении.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Вместо вступления

Прежде всего хочется выразить признательность всем, кто откликнулся на первую статью об оптимизации кода на языке C/C++ на примере функции для вычисления квадратного корня из целого с округлением до ближайшего целого. Благодаря экспертному вниманию была исправлена опечатка в тексте; копилка эффективных алгоритмов пополнилась.

Интересен алгоритм sqrxi32 от @Sdima1357 Пример 1, далее для краткости именуемый как _i32. Алгоритм _i32 безусловно выполняет главное условие задачи округление до ближайшего целого на всём множестве значений аргумента [ 0 .. 0xFFFFFFFF ], при этом показывает высокую производительность.

Пример 1: Вычисление квадратного корня из целого с округлением до ближайшего целого.

uint16_t sqrxi32( uint32_t y ){if ( y == 1 )return 1;uint32_t xh = y > 0x10000ul ? 0x10000ul : y;uint32_t xl = 0;uint32_t xc;for ( int k = 0; k < 16; k++ ){xc = ( xh + xl ) >> 1ul;if ( xc * xc - xc >= y ){xh = xc;}else{xl = xc;}}return ( xh + xl ) >> 1ul;}

Другое хорошее качество алгоритма _i32 предсказуемость по времени. Время работы _i32 постоянно в отличие от алгоритма _evn, потребляющего машинное время пропорционально модулю аргумента.

О чём этот текст

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

Исходный код содержит содержит решение одной задачи разными алгоритмами.

Анализ результатов наблюдений за рамками настоящей публикации.

Условия и допуски

Для сокращение текста принимаем:

• аппаратных платформ для тестов 3 платформы;

• вариантов оптимизации сборки 3 значения

Для сборки двоичного кода применяем:

• Одну единицу компиляции теста (файл main.c)

• Компиляцию в моно-поточный исполняемый файл

• Единую сборочную среду: CubeIDE (она же Eclipce CDT)

• Стандартные настройки профиля сборки RELEASE в среде CubeIDE

• Единый диалект компилятора: ISO C11 + gnu extensions (-std=gnu11)

• Применительно к микроконтроллерам:

  • CubeMX default settings, +48MHz, +USART1, +HAL;

  • Runtime lib: Reduced C ( --spec=nano.specs );

  • Use float with printf from new lib nano ( -u _printf_float );

Таблица 1: Варианты сборки исполняемого кода

Таблица 2: Общие характеристики аппаратных платформ

Таблица 3: Технические характеристики аппаратных платформ

Тестовый набор содержит некоторые алгоритмы из предыдущей статьи и комментариев к ней.

Для оценки FPU платформы M4 в тестовый набор добавлена функция sqrt_fps, решающая вычислительную задачу с применением коротких действительных (float), именуемая далее _fps (Float Point Short) Пример 2.

Пример 2: Квадратный корень из целого с точностью float

uint16_t sqrt_fps( uint32_t number ){if ( number < 2 )return (uint16_t) number;float f_rslt = sqrtf( number );uint32_t rslt = (uint32_t) f_rslt;if ( !( f_rslt - (float) rslt < .5 ) )rslt++;return (uint16_t) rslt;}

Функция _fps работает без ошибок с аргументом менее 22-х бит, что соответствует десятичному порядку 1+E5 Иллюстрация 1.

Иллюстрация 1: Ошибки функции "_fps" на порядках 1+E6+

Для всех наблюдаемых алгоритмов ограничиваем диапазон аргумента множеством значений
[0 .. 1+E5].

Таблица 4: Список наблюдаемых алгоритмов

Основная единица измерения производительность, среднее число циклических вызовов функции за одну миллисекунду.

Относительная производительность платформ

Ожидаемо, производительность платформы x86 выше производительности платформы ARM Cortex безотносительно характера оптимизации сборки. Последнее демонстрирует левая часть графика Иллюстрация 2.

Иллюстрация 2: Относительная производительность аппаратных платформ

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

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

График каждой платформы, в свою очередь, представлен тремя столбцами, демонстрирующими зависимость производительности от варианта оптимизации сборки: -O0, -Os, -O3.

Правая часть графика (Иллюстрация 2) показывает относительный прирост производительности у каждой аппаратной платформы в зависимости от варианта оптимизации сборки: -O0, -Os, -O3.

Производительность 100% демонстрирует двоичный код, собранный без оптимизации ( -O0 ). Это базовая производительность платформы.

Чем выше высота столбика относительно базовой производительности (O0) в правой части графика, тем лучше оптимизационные возможности программно-аппаратной платформы.

Наблюдаем наибольший прирост производительности от оптимизации на этапе сборки наплатформе M4.

Платформа x86

На графике (Иллюстрация 3) по оси Y отображается число цикличных вызовов наблюдаемых функций за одну миллисекунду. На оси X наблюдаемые функции (Таблица 4).

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

Цветом на оси X обозначен способ оптимизации на этапе сборки. Соответствие цвета и характера оптимизации отражает легенда.

Иллюстрация 3: Производительность алгоритмов на платформе x86

Платформа x86 максимально раскрывает преимущества алгоритмов с плавающей точкой перед целочисленными.

Заслуживает отдельного внимания часть графика в оранжевом контуре.

Производительность кода без оптимизации (O0) лучше на 39% для алгоритма _fpu (Os) и на 16% для алгоритма _fps (O3). Другими словами, любая оптимизация на этапе сборки снижает производительность платформы x86 на действительных числах.

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

Платформа M4

Платформа M4 демонстрирует предсказуемый результат (Иллюстрация 4).

Иллюстрация 4: Производительность алгоритмов на платформе M4

Модуль с плавающей точкой M4 даёт ожидаемый прирост производительности для алгоритма _fps, основанного на коротком действительном float.

Последнее подтверждается результатом сравнения производительности алгоритмов при отключенном модуле FPU на платформе M4 Иллюстрация 5.

Наблюдая графики помним, что точность вычислений алгоритма _fps гарантируется в диапазоном 1+E5 (см. Иллюстрация 1) без относительно того, включен ли модуль FPU на M4 или нет.

Иллюстрация 5: Производительность алгоритмов на платформе M4 без FPU

Платформа M0

Результаты платформы M0 похожи на результаты платформы M4безFPU (Иллюстрация 5), только медленнее Иллюстрация 6.

Заметим, тактовая частота при тестировании устанавливалась одинаковой и для M4, и для M0 48 MHz. Однако, производительность M0 хуже в два с лишним раза, чем M4, в условиях равенства прочих характеристик.

Иллюстрация 6: Производительность алгоритмов на платформе M0

Алгоритм _fps на платформе M0 ожидаемо опережает в два раза алгоритм _fpu.

Целочисленные алгоритмы опережают алгоритмы с плавающей точкой.

По странному стечению обстоятельств в заключительном графике (Иллюстрация 6) снова есть место для оранжевого контура.

При сборке без оптимизации (O0) алгоритм _evn быстрее алгоритма _i32. И алгоритм _evn медленнее, чем _i32, если сборка проводится с оптимизацией.

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

Вместо заключения

Производительность программы зависит от многих причин.

Оптимизация на этапе сборки способна ухудшать производительность, замедлять программу, что демонстрируют экспериментальные данные в оранжевых контурах выше (Иллюстрация 3 и Иллюстрация 6).

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

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

Приложение 1. Порядок тестирования платформы x86

1. Создать в среде CubeIDE (Eclipse CDT) проект C штатным способом

2. Написать текст программы Пример 3

3. Добавить в проект файл sqrt_cmp.h Пример 6

4. Осуществить сборку и запуск программы:

   1. штатными средствами IDE;

   2. или из командной строки Пример 4

5. Меняя вид оптимизации ( -O0, -O3, -Os ) наблюдать результат.

Пример 3: Исходный текст программы x86 main.c

#include sqrt_cmp.hint main( void ){main_Of_SqrtComp();return 0;}

Пример 4 Запуск теста на платформе x86 из терминала

gcc main.c -o main -I. -Wall -lm -std=gnu11 -O3 && ./main

Запуск теста из терминала платформы x86 предполагает, что файлы main.c и sqrt_cmp.h располагаются в одном каталоге, и этот каталог выбран рабочим (pwd).

Иллюстрация 7: Запуск теста из терминала x86

Приложение 2. Порядок тестирования платформы STM32

1. Создать в среде CubeIDE проект STM32 штатным способом (CubeMX)

2. Добавить файл sqrt_cmp.h в проект STM32 Пример 6

3. Включить sqrt_cmp.h в файл main.c Пример 5

4. Осуществить сборку и запуск программы штатными средствами IDE

5. Меняя вид оптимизации ( -O0, -O3, -Os ) наблюдать результат

Пример 5: Исходный текст для STM32 (с пропусками < ... >) main.c

<  >/* Private includes ----------------------------------------------------------*//* USER CODE BEGIN Includes */#include "sqrt_cmp.h"/* USER CODE END Includes */<  >/**  * @brief  The application entry point.  * @retval int  */int main(void){<  >  /* Infinite loop */  /* USER CODE BEGIN WHILE */  main_Of_SqrtComp();  while (1)  {    /* USER CODE END WHILE */    /* USER CODE BEGIN 3 */  }  /* USER CODE END 3 */

Приложение 3. Порядок тестирования других алгоритмов и платформ

Сборка теста для других платформ проводится по аналогии.

Для отличных от упомянутых выше аппаратных платформ (Таблица 3), вероятно, потребуется косметическая модификация файла sqrt_cmp.h.

Пример 6: Содержание файла sqrt_cmp.h

/****************************************************************************** * File: sqrt_cmp.h Created on 5 авг. 2020 г. * CC0 1.0 Universal (CC0 1.0) * Creative Commons Public Domain Dedication * No Copyright * * TAB Size .EQ 4 ********************************************************************************/#ifndef __SQRT_CMP_H#define __SQRT_CMP_H#include<math.h>#include<stdio.h>#include<stdint.h>#ifdef __cplusplusextern "C" {#endif/****************************************************************************** * Interface of the entry point for all sqrt tests ******************************************************************************/void main_Of_SqrtComp();/****************************************************************************** * test case selection: TEST_SET * select one of the test suite via a comment. ******************************************************************************/#define TEST_SETTEST_ALL//#define TEST_SETTEST_ROUNDING//#define TEST_SETTEST_PERFORMANCE/****************************************************************************** * Interfaces of test functions. * See implementation of them at the end of this file. ******************************************************************************/typedef uint16_t (*sqrt_func)( uint32_t number );uint16_t sqrt_fpu( uint32_t number );// floating point function from articleuint16_t sqrt_evn( uint32_t number );// integer function from articleuint16_t sqrxi32( uint32_t y );// integer function from comment byuint16_t sqrt_fps( uint32_t number );// optimized floating point function for Cortex M4// <-- insert interface of your function here/****************************************************************************** * Set to variable named as 'round_test_func' below * to the alias of one of the functions above. * The NULL will select last function in comp_list[] ******************************************************************************/sqrt_func round_test_func = sqrt_fps;// specific instance for the rounding test//sqrt_func round_test_func = sqrxi32;// specific instance for the rounding test//sqrt_func round_test_func = sqrt_evn;// specific instance for the rounding test//sqrt_func round_test_func = NULL;// last function in comp_list[]/****************************************************************************** * The array of test functions for competing routines is called comp_list[]. * Adding a new function to the test: - copy the implementation of the new function to the end of this file; - declare the function interface at the beginning of this file; - add the alias and declaration of the new function to end of array named comp_list[]. ******************************************************************************/// @formatter:offtypedef struct{sqrt_funcfsqrt;char *alias;} SCompFunc;SCompFunc comp_list[] =// competition list{{ sqrt_fpu, "_fpu" },{ sqrt_fps, "_fps" },{ sqrt_evn, "_evn" },{ sqrxi32,  "_i32" }// <-- insert your function name & alias here};/* @formatter:on *//****************************************************************************** * Platform-independent definitions ******************************************************************************/#define PUT_FORMAT_MSG(f_, ...) { \sprintf( (char *)s_buf, (char *)f_, ##__VA_ARGS__ ); \PUT_MSG( (char *)s_buf ); }#define MS_PER_SEC1000#define US_PER_SEC( MS_PER_SEC * MS_PER_SEC )#define ARRAY_SIZE(a) (sizeof a / sizeof *a)// size of static array at runtime#define SIRV(f) if ( f ) ;// suppress Ignore Return Value warning/****************************************************************************** * Platform-specific defines ******************************************************************************/#if defined( USE_HAL_DRIVER )// STM32 ARM Cortex platform#include<string.h>#include "main.h"//*****************************************************************************// Platform-specific defines for the helper functions#define SCALE_RATE1// must be .GE than 1#define X_CLOCKHAL_GetTick()#define X_DELAY( ms )HAL_Delay( ms )//*****************************************************************************// Platform-specific defines for the terminal output#define USART_HANDLEhuart1// set valid USART handler alias here defined by the config of MCU#define USART_TIMEOUT150// max timeout for HAL_UART_Transmitextern UART_HandleTypeDef USART_HANDLE;extern HAL_StatusTypeDef HAL_UART_Transmit ( UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout );#define PUT_MSG( msg ) \HAL_UART_Transmit( &USART_HANDLE, (uint8_t *)msg, strlen( (char *)msg ), USART_TIMEOUT )#define CPU_CLOCK_MHz( SystemCoreClock / US_PER_SEC )// CPU CLK in MHz#if defined( STM32F0 )#defineCPU_ID ( "STM32 ARM Cortex M0" )#elif defined ( STM32F3 )#defineCPU_ID ( "STM32 ARM Cortex M4" )#else#defineCPU_ID ( "Maybe STM32 ARM Cortex" )#endif#define PUT_SYS_INFOPUT_FORMAT_MSG( " %s @ "fdU()" MHz\n", CPU_ID, CPU_CLOCK_MHz )#else// #if defined( USE_HAL_DRIVER)#include <time.h>#include <stdlib.h>//*****************************************************************************// Platform-specific defines for the helper functions#define SCALE_RATE100// must be .GE than 1#define X_CLOCK(uint32_t) x_clock()#define X_DELAY( ms )x_delay( ms )uint32_t x_clock(){uint64_t result = (uint64_t) clock();result *= MS_PER_SEC;result /= CLOCKS_PER_SEC;return (uint32_t) result;}void x_delay( uint32_t ms ){uint64_t tm = x_clock();while ( ( x_clock() - tm ) < ms );}//*****************************************************************************// Platform-specific defines for the terminal output#define PUT_MSG( msg ) \printf( "%s", (char *)msg ), fflush ( stdout );#if defined( __unix__ )// anybody other platform for gcc#define PUT_SYS_INFOSIRV( system( "cat /proc/cpuinfo | grep 'model name' | head -1 | sed s/'model name\t:'/''/" ) )#else#define PUT_SYS_INFOPUT_MSG( "Undefined System & CPU" )#endif// #if defined( __unix__ )  // anybody other platform for gcc#endif// #if defined( USE_HAL_DRIVER)#if  ( __WORDSIZE == 64 )#define fdI(s)"%" #s "d"#define fdU(s)"%" #s "u"#define fdX(s)"%" #s "x"#else// let's say __WORDSIZE == 32#define fdI(s)"%" #s "ld"#define fdU(s)"%" #s "lu"#define fdX(s)"%" #s "lx"#endif// #if ( __WORDSIZE == 64 )#if defined ( DEBUG ) || defined ( _DEBUG ) // chk build mode of CubeIDE#defineBUILD_MODE"DEBUG"#else // Maybe Release#defineBUILD_MODE"RELEASE"#endif// #if defined ( DEBUG ) || defined ( _DEBUG )/****************************************************************************** * the helper data with testing ranges ******************************************************************************/// @formatter:offtypedef struct{uint32_tstart;uint32_tstop;uint32_trepeat;} STestRange;STestRangetest_rngs[] ={{ 0, 1000, 100 * SCALE_RATE },{ 0, 10000, 10 * SCALE_RATE },{ 0, 100000, 1 * SCALE_RATE }};uint32_t test_results[ARRAY_SIZE( test_rngs )][ARRAY_SIZE( comp_list ) + 1];#define MSG_BUFF_SIZE512uint8_t s_buf[MSG_BUFF_SIZE];// buffer for a terminal output/* @formatter:on *//****************************************************************************** * Test sets definitions. Do not change it. ******************************************************************************/#define TEST_ROUNDING1#define TEST_PERFORMANCE2#define TEST_ALL( TEST_ROUNDING | TEST_PERFORMANCE )#ifndef TEST_SET#defineTEST_SETTEST_ALL#endif#define HI_ROUND_TEST_RANGE_END0x007FFFFFUL#define HI_ROUND_TEST_RANGE_START( HI_ROUND_TEST_RANGE_END >> 4 )/****************************************************************************** * Interface of helper functions ******************************************************************************/void main_Header();void testRounding();void testPerformance();/****************************************************************************** * Implementation of the entry point for all sqrt tests ******************************************************************************/void main_Of_SqrtComp(){X_DELAY( MS_PER_SEC / 2 );// suppress the output of a previous instance// while the new instance is loading into the MCUuint32_t start_time = X_CLOCK;main_Header();// checking normal and extended ranges for roundingif ( TEST_SET & TEST_ROUNDING )testRounding();// checking normal ranges on execution timeif ( TEST_SET & TEST_PERFORMANCE )testPerformance();uint32_t test_time = X_CLOCK - start_time;uint32_t test_m = ( test_time / MS_PER_SEC ) / 60;uint32_t test_s = ( test_time / MS_PER_SEC ) % 60;uint32_t test_ms = test_time % MS_PER_SEC;PUT_FORMAT_MSG( "\ndone, spent time: "fdU()" m, "fdU()"."fdU()" s\n", test_m, test_s, test_ms );}/****************************************************************************** * Implementation of the helper functions ******************************************************************************/void main_Header(){PUT_MSG( "\n\n**********************************************************\n" );PUT_SYS_INFO;PUT_FORMAT_MSG( "*********** %s, built at %s\n", BUILD_MODE, __TIME__ );}void testPerformance(){uint32_t i_func, i_rpt, i_rng;uint32_t number, first, second, diff;uint64_t temp;PUT_MSG( "----------+ Performance test" );for ( i_rng = 0; i_rng < ARRAY_SIZE( test_rngs ); i_rng++ ){PUT_MSG( "\n" );PUT_FORMAT_MSG( "test range:["fdU()".."fdU()"], repeat="fdU()"\n", test_rngs[i_rng].start, test_rngs[i_rng].stop,test_rngs[i_rng].repeat );test_results[i_rng][0] = test_rngs[i_rng].stop;for ( i_func = 0; i_func < ARRAY_SIZE( comp_list ); i_func++ ){PUT_FORMAT_MSG( "%s ... ", comp_list[i_func].alias );first = X_CLOCK;for ( i_rpt = 0; i_rpt < test_rngs[i_rng].repeat; i_rpt++ )for ( number = test_rngs[i_rng].start; number < test_rngs[i_rng].stop; number++ )comp_list[i_func].fsqrt( number );second = X_CLOCK;diff = second - first;temp = ( test_rngs[i_rng].stop - test_rngs[i_rng].start ) * test_rngs[i_rng].repeat;test_results[i_rng][i_func + 1] = (uint32_t) ( temp / diff );if ( i_func < ARRAY_SIZE( comp_list ) - 1 )PUT_MSG( ", " );}}// small reportPUT_FORMAT_MSG( "\n----------+ Report: sqrt`s calls per ms\n%10s", "range" );for ( i_func = 0; i_func < ARRAY_SIZE( comp_list ); i_func++ )PUT_FORMAT_MSG( "%10s", comp_list[i_func].alias );for ( i_rng = 0; i_rng < ARRAY_SIZE( test_rngs ); i_rng++ ){PUT_MSG( "\n" );for ( i_func = 0; i_func < ARRAY_SIZE( comp_list ) + 1; i_func++ )PUT_FORMAT_MSG( fdU( 10 ), test_results[i_rng][i_func] );}PUT_FORMAT_MSG( "\n----------+\n%10s", "average" );for ( i_func = 0; i_func < ARRAY_SIZE( comp_list ); i_func++ ){temp = 0;for ( i_rng = 0; i_rng < ARRAY_SIZE( test_rngs ); i_rng++ )temp += test_results[i_rng][i_func + 1];temp /= ARRAY_SIZE( test_rngs );PUT_FORMAT_MSG( fdU( 10 ), (uint32_t)temp );}}void testRoundingFunction( uint32_t start, uint32_t finish, sqrt_func psqrt, char *fname );void testRounding(){uint16_t i_rng;uint16_t f_rng;PUT_MSG( "----------+ Rounding test\n" );// checking the existence for the test functionfor ( f_rng = 0; f_rng < ARRAY_SIZE( comp_list ); f_rng++ )if ( comp_list[f_rng].fsqrt == round_test_func )break;if ( !( f_rng < ARRAY_SIZE( comp_list ) ) ){f_rng = ARRAY_SIZE( comp_list ) - 1;PUT_FORMAT_MSG( "Value of 'round_test_func' not found.\n" );}PUT_FORMAT_MSG( "Function '%s' is tested for rounding.\n", comp_list[f_rng].alias );// checking standard rangesfor ( i_rng = 0; i_rng < ARRAY_SIZE( test_rngs ); i_rng++ )testRoundingFunction( test_rngs[i_rng].start, test_rngs[i_rng].stop, comp_list[f_rng].fsqrt, comp_list[f_rng].alias );// checking extended rangetestRoundingFunction( HI_ROUND_TEST_RANGE_START, HI_ROUND_TEST_RANGE_END, comp_list[f_rng].fsqrt, comp_list[f_rng].alias );}void turn_the_fan( uint32_t ms );void testRoundingFunction( uint32_t start, uint32_t finish, sqrt_func psqrt, char *fname ){uint32_t rf, ri;uint32_t n, c = 0;PUT_FORMAT_MSG( "test range:["fdU( 10 )".."fdU( 10 )"] ... ", start, finish );for ( n = start; n < finish; n++ ){rf = sqrt_fpu( n );ri = ( *psqrt )( n );if ( rf != ri ){if ( c++ > 3 ){PUT_FORMAT_MSG( "\b\n(!)too many mistakes in '%s', ", fname );break;}else{double d = sqrt( (double) n );PUT_FORMAT_MSG( "\b\n%s("fdU( 10 )")="fdU()" != "fdU(), fname, n, ri, rf );PUT_FORMAT_MSG( " (real value is %.6lf)", d );}}turn_the_fan( MS_PER_SEC );}if ( !c ){PUT_FORMAT_MSG( "\b done.\n" );}else{PUT_FORMAT_MSG( "test failed.\n" );}}void turn_the_fan( uint32_t ms ){static char ca[] = "|/-\\";static uint32_t cs = ARRAY_SIZE(ca) - 1;static uint32_t cn = 0;static uint32_t at = 0;uint32_t ct = X_CLOCK;if ( ct - at > ms ){at = ct;PUT_FORMAT_MSG( "\b%c", ca[cn++ % cs] );}}/****************************************************************************** * Implementation of the sqrt functions ******************************************************************************/// floating point arg & result with doubleuint16_t sqrt_fpu( uint32_t number ){if ( number < 2 )return (uint16_t) number;double f_rslt = sqrt( number );uint32_t rslt = (uint32_t) f_rslt;if ( !( f_rslt - (double) rslt < .5 ) )rslt++;return (uint16_t) rslt;}// floating point arg & result with floatuint16_t sqrt_fps( uint32_t number ){if ( number < 2 )return (uint16_t) number;float f_rslt = sqrtf( number );uint32_t rslt = (uint32_t) f_rslt;if ( !( f_rslt - (float) rslt < .5 ) )rslt++;return (uint16_t) rslt;}// unsigned integer arg & result// @formatter:offuint16_t sqrt_evn ( uint32_t number ){if ( number < 2 )return ( uint16_t ) number;uint32_t temp;uint32_t div;uint32_t rslt;if ( number & 0xFFFF0000L )if ( number & 0xFF000000L )if ( number & 0xF0000000L )if ( number & 0xE0000000L )div = 43771;elsediv = 22250;elseif ( number & 0x0C000000L )div = 11310;elsediv = 5749;elseif ( number & 0x00F00000L )if ( number & 0x00C00000L )div = 2923;elsediv = 1486;elseif ( number & 0x000C0000L )div = 755;elsediv = 384;elseif ( number & 0xFF00L )if ( number & 0xF000L )if ( number & 0xC000L )div = 195;elsediv = 99;elseif ( number & 0x0C00L )div = 50;elsediv = 25;elseif ( number & 0xF0L )if ( number & 0x80L )div = 13;elsediv = 7;elsediv = 3;rslt = number;while ( 1 ){temp = number / div;temp += div;div = temp >> 1;div += temp & 1;if ( rslt > div )rslt = div;else{if ( number / rslt == rslt - 1 && number % rslt == 0 )rslt--;return ( uint16_t ) rslt;}}}/* @formatter:on */// unsigned integer arg & resultuint16_t sqrxi32( uint32_t y ){if ( y == 1 )return 1;uint32_t xh = y > 0x10000ul ? 0x10000ul : y;uint32_t xl = 0;uint32_t xc;for ( int k = 0; k < 16; k++ ){xc = ( xh + xl ) >> 1ul;if ( xc * xc - xc >= y ){xh = xc;}else{xl = xc;}}return ( xh + xl ) >> 1ul;}// <-- insert implementation of your function sqrt here#ifdef __cplusplus}#endif#endif // __SQRT_CMP_H

Kubernetes спроектирован так, чтобы быть надежным и устойчивым к сбоям, а также иметь возможность автоматически восстанавливаться. И он отлично справляется со всем этим! Однако рабочие узлы могут по разным причинам терять подключение к кластеру или выходить из строя. В этих случаях необходимо, чтобы Kubernetes быстро среагировал на инцидент.

Когда узел выходит из строя, pods сломанного узла все еще работают в течение некоторого времени. При этом они продолжают получать запросы, и эти запросы фейлятся. Скорее всего, совсем не то поведение, которое вы ожидали от Kubernetes, верно?

Чтобы разобраться, как Kubernetes реагирует на выход узла из строя, сначала рассмотрим взаимодействие между Kubelet и Controller Manager:

1. Kubelet периодически уведомляет kube-apiserver о своём статусе с интервалом, заданным в параметре --node-status-update-frequency. Значение по умолчанию 10 секунд.

2. Controller manager проверяет статус Kubelet каждые -node-monitor-period. Значение по умолчанию 5 секунд.

3. Если от Kubelet получена информация в пределах --node-monitor-grace-period, Controller manager считает Kubelet исправным. Значение по умолчанию 40 секунд.

В случае отказа узла кластера происходит следующий алгоритм:

1. Kubelet отправляет свой статус kube-apiserver, используя - node-status-update-frequency = 10 сек.

2. Узел выходит из строя.

3. Controller manager будет пытаться проверять статус узла, сообщаемый Kubelet, каждые --node-monitor-period = 5 сек.

4. Controller manager увидит, что узел не отвечает, и даст ему тайм-аут --node-monitor-grace-period в 40 сек. Если за это время Controller manager не сочтет узел исправным, он установит статус NotReady.

5. Kube Proxy удалит endpoints, указывающие на pods внутри этого узла из всех сервисов, поэтому pods сбойного узла больше не будут доступны.

В этом сценарии будет возможны ошибки при обращении в pods, работающим на этом узле, потому что модули будут продолжать получать трафик до тех пор, пока узел не будет считаться неработающим (NotReady) через 45 сек.

Есть множество параметров для настройки в Kubelet и Controller Manager.

Быстрое обновление и быстрая реакция

Чтобы увеличить скорость реакции Kubernetes на отказ узлов кластера, вы можете изменить эти параметры:

-node-status-update-frequency установить значение 1 сек (по умолчанию 10 сек)

--node-monitor-period установить значение 1 сек (по умолчанию 5 сек )

--node-monitor-grace-period установить значение 4 сек (по умолчанию 40 сек)

Протестируем изменения

Чтобы проверить изменения в тестовой среде, мы можем создать кластер Kubernetes с помощью Kind или любого другого инструмента. Мы создали конфигурационный файл для Kind Cluster с параметрами, указанными в предыдущем разделе, чтобы протестировать поведение кластера.

kind: ClusterapiVersion: kind.x-k8s.io/v1alpha4kubeadmConfigPatches:- |  apiVersion: kubelet.config.k8s.io/v1beta1  kind: KubeletConfiguration  nodeStatusUpdateFrequency: 1snodes:- role: control-plane  kubeadmConfigPatches:  - |    kind: ClusterConfiguration    controllerManager:        extraArgs:          node-monitor-period: 1s          node-monitor-grace-period: 4s- role: worker

Затем мы устанавливаем deployment с двумя репликами Nginx, размещенными в control-plane и на worker. Также мы дополнительно создали на control-plane pod с Ubuntu, чтобы проверить доступность Nginx, когда worker станет недоступен.

#!/bin/bash# create a K8S cluster with Kindkind create cluster --config kind.yaml # create a Ubuntu pod in control-plane Nodekubectl run ubuntu --wait=true --image ubuntu --overrides='{"spec": { "nodeName": "kind-control-plane"}}' sleep 30d# untaint control-plane node in order to schedule pods on itkubectl taint node kind-control-plane node-role.kubernetes.io/master-# create Nginx deployment with 2 replicas, one on each nodekubectl create deploy ng --image nginxsleep 30kubectl scale deployment ng --replicas 2# expose Nginx deployment so that is reachable on port 80kubectl expose deploy ng --port 80  --type ClusterIP# install curl in Ubuntu podkubectl exec ubuntu -- bash -c "apt update && apt install -y curl"

Чтобы проверить доступность Nginx, мы обратились к сервису с помощью curl из pod с Ubuntu, размещенного в control-plane, а также наблюдали за endpoints, принадлежащими сервису Nginx из терминала.

# test Nginx service access from Ubuntu podkubectl exec ubuntu -- bash -c 'while true ; do echo "$(date +"%T.%3N") - Status: $(curl -s -o /dev/null -w "%{http_code}" -m 0.2 -i ng)" ; done'# show Nginx service endpointswhile true; do  gdate +"%T.%3N"; kubectl get endpoints ng -o json | jq '.subsets' | jq '.[] | .addresses' | jq '.[] | .nodeName'; echo "------";done

Наконец, чтобы смоделировать сбой узла, мы остановили контейнер Kind, в котором запущен рабочий узел. Мы также добавили отметки времени, чтобы узнать когда узел был отключен и когда узел был обнаружен как NotReady.

#!/bin/bash# kill Kind worker nodeecho "Worker down at $(gdate +"%T.%3N")"docker stop kind-worker > /dev/nullsleep 15# show when the node was detected to be downecho "Worker detected in down state by Control Plane at "kubectl get event --field-selector reason=NodeNotReady --sort-by='.lastTimestamp' -oyaml | grep time | tail -n1# start worker node againdocker start kind-worker > /dev/null

После запуска теста мы заметили, что узел отключился в 12:50:22, а Controller manager обнаружил, что он отключился в 12:50:26, что и следовало ожидать через 4 секунды.

Worker down at 12:50:22.285Worker detected in down state by Control Plane at      time: "12:50:26Z"

Аналогичный результат при тестировании с терминала. Служба начала возвращать сообщения об ошибках в 12:50:23, потому что трафик был направлен на отказавший узел. А в 12:50:26.744 Kube Proxy удалил endpoint, указывающую на отказавший узел, и доступность службы была полностью восстановлена.

...12:50:23.115 - Status: 20012:50:23.141 - Status: 20012:50:23.161 - Status: 20012:50:23.190 - Status: 00012:50:23.245 - Status: 20012:50:23.269 - Status: 20012:50:23.291 - Status: 00012:50:23.503 - Status: 20012:50:23.520 - Status: 00012:50:23.738 - Status: 00012:50:23.954 - Status: 00012:50:24.166 - Status: 00012:50:24.385 - Status: 20012:50:24.407 - Status: 00012:50:24.623 - Status: 00012:50:24.839 - Status: 00012:50:25.053 - Status: 00012:50:25.276 - Status: 20012:50:25.294 - Status: 00012:50:25.509 - Status: 20012:50:25.525 - Status: 20012:50:25.541 - Status: 20012:50:25.556 - Status: 20012:50:25.575 - Status: 00012:50:25.793 - Status: 20012:50:25.809 - Status: 20012:50:25.826 - Status: 20012:50:25.847 - Status: 20012:50:25.867 - Status: 20012:50:25.890 - Status: 00012:50:26.110 - Status: 00012:50:26.325 - Status: 00012:50:26.549 - Status: 00012:50:26.604 - Status: 20012:50:26.669 - Status: 00012:50:27.108 - Status: 20012:50:27.135 - Status: 20012:50:27.162 - Status: 20012:50:27.188 - Status: 200......------12:50:26.523"kind-control-plane""kind-worker"------12:50:26.618"kind-control-plane""kind-worker"------12:50:26.744"kind-control-plane"------12:50:26.878"kind-control-plane"------...

Заключение

Мы убедились, что скорость реакции Kubernetes на инцидент значительно возросла. Возможны разные комбинации параметров для конкретных случаев, и у вас может возникнуть соблазн снизить значения, чтобы система Kubernetes реагировала быстрее, но примите во внимание, что этот сценарий создает накладные расходы на etcd, поскольку каждый узел будет постоянно пытаться обновлять свой статус через 1 секунду. Например, если в кластере 1000 узлов, будет происходить 60000 обновлений узлов в минуту, что может потребовать увеличения ресурсов контейнеров etcd или даже выделенных узлов для etcd.

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

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

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

Prometheus одно из самых популярных решений для мониторинга кластеров Kubernetes. Поэтому каждый шаг в этом руководстве содержит примеры запросов PromQL.

Обнаружение контейнеров без ограничения ресурсов

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

Отсутствие лимитов в контейнере может оказать негативное воздействие на узлы кластера. В лучшем случае узлы начнут выселять pods с учетом QoS. При этом также возникнут проблемы с производительностью из-за троттлинга процессора. Но в худшем случае узел может перестать работать из-за нехватки ресурсов.

Контейнеры без CPU Limit в каждом namespace

sum by (namespace)(count by (namespace,pod,container)(kube_pod_container_info{container!=""}) unless sum by (namespace,pod,container)(kube_pod_container_resource_limits{resource="cpu"}))

Контейнеры без Memory Limit в каждом namespace

sum by (namespace)(count by (namespace,pod,container)(kube_pod_container_info{container!=""}) unless sum by (namespace,pod,container)(kube_pod_container_resource_limits{resource="memory"}))

Допустим, вы нашли несколько контейнеров без ограничений ресурсов. Как определить потенциально опасные? Легко! Нужно найти контейнеры, которые используют больше всего ресурсов и при этом не имеют лимитов.

Топ-10 контейнеров без CPU Limits, потребляющих больше всего ресурсов CPU

topk(10,sum by (namespace,pod,container)(rate(container_cpu_usage_seconds_total{container!=""}[5m])) unless sum by (namespace,pod,container)(kube_pod_container_resource_limits{resource="cpu"}))

Топ-10 контейнеров без Memory Limits, потребляющих больше памяти

topk(10,sum by (namespace,pod,container)(container_memory_usage_bytes{container!=""}) unless sum by (namespace,pod,container)(kube_pod_container_resource_limits{resource="memory"}))

Обнаружение контейнеров со слишком строгими ограничениями

Обнаружение контейнеров со слишком строгими CPU Limits

Если утилизация контейнером ресурсов процессора приближается к установленному лимиту, то его производительность будет снижаться из-за троттлинга ЦП.

Выполните этот запрос, чтобы найти контейнеры, для которых использование ЦП близко к пределу:

(sum by (namespace,pod,container)(rate(container_cpu_usage_seconds_total{container!=""}[5m])) / sum by (namespace,pod,container)(kube_pod_container_resource_limits{resource="cpu"})) > 0.8

Обнаружение контейнеров со слишком строгими Memory Limits

Если контейнер превысит лимит по памяти, он будет убит.

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

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

(sum by (namespace,pod,container)(container_memory_usage_bytes{container!=""}) / sum by (namespace,pod,container)(kube_pod_container_resource_limits{resource="memory"})) > 0.8

Как выбрать оптимальные значения для лимитов?

Один из способов выбрать оптимальные значения для лимитов наблюдение за утилизацией ресурсов контейнером в течение некоторого времени. Мы можем использовать две стратегии:

Консервативная

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

Находим оптимальный CPU Limit с помощью консервативной стратегии:

max by (namespace,owner_name,container)((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[5m])) * on(namespace,pod) group_left(owner_name) avg by (namespace,pod,owner_name)(kube_pod_owner{owner_kind=~"DaemonSet|StatefulSet|Deployment"}))

Находим оптимальный Memory Limit с помощью консервативной стратегии:

max by (namespace,owner_name,container)((container_memory_usage_bytes{container!="POD",container!=""}) * on(namespace,pod) group_left(owner_name) avg by (namespace,pod,owner_name)(kube_pod_owner{owner_kind=~"DaemonSet|StatefulSet|Deployment"}))

Агрессивная

Задаем ограничение ресурсов по 99 квантилю. Это позволит не учитывать 1% наиболее высоких значений. Это хорошая стратегия, если есть редкие аномалии или пики, которые вы хотите игнорировать.

Находим оптимальный CPU Limit с помощью агрессивной стратегии:

quantile by (namespace,owner_name,container)(0.99,(rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[5m])) * on(namespace,pod) group_left(owner_name) avg by (namespace,pod,owner_name)(kube_pod_owner{owner_kind=~"DaemonSet|StatefulSet|Deployment"}))

Находим оптимальный Memory Limit с помощью агрессивной стратегии:

quantile by (namespace,owner_name,container)(0.99,(container_memory_usage_bytes{container!="POD",container!=""}) * on(namespace,pod) group_left(owner_name) avg by (namespace,pod,owner_name)(kube_pod_owner{owner_kind=~"DaemonSet|StatefulSet|Deployment"}))

Достаточно ли ресурсов в вашем кластере?

Узлы кластера гарантируют, что запланированные в них pods будут иметь достаточно ресурсов на основе параметра Requests контейнера каждого pods. К тому же, узлы резервируют за каждым контейнером указанный объем памяти и количество ядер ЦП.

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

Когда вы утилизируете большую часть ресурсов кластера, контейнеры могут работать без проблем при обычной нагрузке, но в сценариях с высокой нагрузкой контейнеры могут начать использовать ЦП и память до предела. Это приведет к тому, что узел начнет выселять pods, а в критических ситуациях узел перестанет работать из-за нехватки ресурсов.

Как обнаружить превышение доступных ресурсов кластера?

Процент превышения доступных ресурсов по памяти:

100 * sum(kube_pod_container_resource_limits{container!="",resource="memory"} ) / sum(kube_node_status_capacity_memory_bytes)

Процент превышения доступных ресурсов по ЦП:

100 * sum(kube_pod_container_resource_limits{container!="",resource="cpu"} ) / sum(kube_node_status_capacity_cpu_cores)

Как правило, не все контейнеры полностью утилизируют запрашиваемые ресурсы одновременно. Если заданные лимиты составляют 100% от ресурсов кластера это повлечет за собой дополнительные затраты на инфраструктуру, которая никогда не будет использоваться.

Лучшим решением будет выбрать консервативную стратегию, гарантирующую, что избыточное использование составляет менее 125%, или агрессивную стратегию, которая позволяет лимитам достичь 150% емкости вашего кластера.

Не менее важным будет проверка соответствия лимитов емкости каждого узла. Например, у нас есть контейнер с CPU Requests - 2 и CPU Limit - 8. Этот контейнер можно запланировать на узле с 4 ядрами, но лимиты не дадут нужного эффекта, потому что на узле недостаточно ядер.

Процент превышения доступных ресурсов узла по памяти:

sum by (node)(kube_pod_container_resource_limits{container!=,resource=memory} ) / sum by (node)(kube_node_status_capacity_memory_bytes)

Процент превышения доступных ресурсов узла по ЦП:

sum by (node)(kube_pod_container_resource_limits{container!=,resource=cpu} ) / sum by (node)(kube_node_status_capacity_cpu_cores)

Подведем итоги

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

Если вы хотите узнать больше, рекомендуем прочитать статью рациональное использовании ресурсов в Kubernetes.

Разбираем аргументы за и против. В конце также можно ознакомиться с моим мнением на этот счет.

С чего все начиналось?

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

Немного обо мне: я Python разработчик, архитектор, тимлид. В программировании с 2009 года. Ранее опубликовал эту статью на vc.ru.

В реализации проекта мне помогал аналитик от заказчика, и в общем-то всё.

Итак, к кейсу

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

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

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

Как решить проблему потери времени? У сотрудника должна быть возможность коннектиться с CRM-системой с планшета или телефона.

Как осуществить задуманное?

Выход нашёлся быстро: создать чат-бот в Telegram.

И на это решение можно посмотреть с двух сторон: с позиции управленцев и со стороны айтишников.

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

Если рассуждать со стороны управленцев, соединение CRM-системы с чат-ботом Telegram значительно снижает энергозатраты и финансовые расходы компании. И вот, почему:

• Не нужно обучать большой штат новым программам-интеграторам CRM с телефоном.

• Тем более, стоимость таких программ значительно выше, чем стоимость написания и поддержания работоспособности чат-бота для Telegram.

• Это удобно. Сейчас у каждого есть возможность скачать Telegram, который не занимает много места в памяти телефона.

• Работает Telegram-бот действительно быстрее, чем сложная программа. Кроме того, чат-бот помогает сотруднику сориентироваться во внутреннем документообороте фирмы.

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

• Интеграция мессенджера в CRM-систему может привести к утечке информации. Сам по себе документооборот необходимо строить на основе внутренних ресурсов, также необходимо предусмотреть авторизацию пользователей. Если не учесть эти моменты, то данные могут уйти не в те руки.

• Если изменить процесс документооборота, например, ввести отправку редактированных вариантов, то решение рассыпается. В таком случае сотруднику необходимо будет сначала отредактировать документ, а потом отправить его в чат с ботом.

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

• Ещё один весомый аргумент: данные будут храниться в разных системах. Telegram-бот может быть напрямую привязан к CRM или ERP-системе, но в большинстве случаев он имеет свое хранилище, в котором агрегирует данные и обрабатывает их.

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

А что я думаю по этому поводу?

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

Тем более, если говорить об удобстве главных героев этой эпопеи - полевых работниках, то загрузить документ и отправить его на дальнейшее согласование, получить нужное уведомление гораздо проще через бот в Telegram, чем через специализированную программу, типа 1C, Диадок и т.д.

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

Даже удивительно, почему другие компании не используют подобные методы. А может и использует, кто их знает?

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

О технической стороне вопроса

Идея была реализована на основе Telegram API на вебхуках. Для разработки был использован любимый python, данные хранятся на базе postgresql. Для ускорения работы и асинхронности задач применили связку redis + celery, в качестве серверной операционной системы использована Ubuntu 18 Server.

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

А вы на стороне программистов или управленцев? Делитесь своим мнением, задавайте вопросы!

Исходные данные:

1. Два SQL Server'а, которые находятся в прямой доступности между собой, на одном из которых настроен Linked Server.

2. SQL запрос вида:

insert into LocalDatabaseName.dbo.TableName (column1, column2, ..., columnN)select column1, column2, ..., columnNfrom LinkedServerName.RemoteDatabaseName.dbo.TableName

Задача: максимально быстро скопировать записи с одного сервера на другой

Столкнулся с тем, что подобный запрос выполняется на 40k (40000) записей больше минуты. С ростом количества подобных запросов или количества записей, производительность сильно падает и оптимизировать запрос средствами SQL никак нельзя. С использованием приложения ImportExportDataSql мне удалось ускорить этот запрос до 2 секунд, не используя Linked Server.

Приложение ImportExportDataSql создавал для себя и постоянно его дорабатывал на протяжении нескольких лет. Основные требования при создании приложения - портативность, работа под всеми версиями Windows без установки сторонних библиотек (кроме NET Framework 3.5), простой интерфейс и высокая производительность.

ImportExportDataSql - универсальный конвертер данных, как альтернатива "bcp"

При работе с данными очень часто требуется загружать файлы из разных файлов в БД (чаще всего CSV и Excel) и обратно (из БД в CSV). До этого пользовался утилитой bcp, но всегда не хватало графического интерфейса. Кроме этого у "bcp", есть недостатки, описанные в моей предыдущей статье.

В ImportExportDataSql кроме графического интерфейса, реализована возможность работы через командную строку. Пример командной строки:

ImportExportDataSql.exe -ConnectionName="Имя соединения с БД" -TaskName="Имя Задачи 1" -TaskName="Имя задачи 2" [-Log="C:\FolderName\LogFileName.log"]

Параметры командной строки:

-ConnectionName - Имя соединения с БД, которое должно быть сохранено на форме "Соединение с БД" по кнопке "Сохранить настройку соединения с БД"

Сохранить настройку соединения с БД

-TaskName - Имя задачи из пользовательского списка задач

-Log - имя лог файла. Необязательный параметр. По-умолчанию, используется лог файл в папке Logs\UserName\ImportExportDataSql.log

Список решаемых задач в ImportExportDataSql

1. Сохранить из БД в файл - если файлы хранятся в БД и их нужно сохранить на диск

2. Сохранить из БД в файл (утилитой bcp) - если файлы хранятся в БД и их нужно сохранить на диск с помощью утилиты bcp (создается bat файл)

3. Сохранить из файла в БД - если нужно загрузить файлы с диска в таблицу БД с полем типа varbinary

4. Сохранить из БД в скрипт SQL - сохраняет результат SELECT запроса в SQL файл

5. Из БД в скрипт SQL (только INSERT)

6. Из БД в скрипт SQL (только UPDATE)

7. Статический скрипт SQL

8. Сохранить из Excel в скрипт SQL

9. Сохранить из БД в CSV

10. Сохранить из CSV в SQL

11. Сохранить из CSV в БД

12. Сохранить конфигурацию БД в SQL - выгружает структуру БД в SQL файл

13. Сохранить из БД в БД - сохраняет результат SELECT запроса на другой или текущий сервер

Все типы обработки, которые заканчиваются словом SQL могут объединяться в один файл, если имя файла одинаковое в нескольких задачах. Это очень удобно для копирования данных из одной БД в другую (например, при переносе данных с прода на тест или наоборот).

Сохранить из БД в БД

Использование данного способа позволило оптимизировать запрос (приведенный в начале статьи) копирования данных через Linked Server, сократив время выполнения с 1 минуты до 2 секунд. Алгоритм копирования данных из одной БД в другую выполнен стандартными классами языка C# из пространства имен System.Data.SqlClient: SqlConnection, SqlDataReader, SqlCommand и SqlBulkCopy.

Чтобы не возникало ошибки нехватки памяти OutOfMemoryException, чтение и запись данных выполняется блоками (частями). Блок ограничивается максимальным количеством записей, который определяется пользователем. Параметры, которые задает пользователь:

1. SQL запрос - выполняется на БД источнике, с которой нужно копировать информацию

2. Настройки выгрузки в БД назначения:

   Имя соединения - выбирается из списка соединений, которые пользователь сохраняет на форме "Соединение с БД", отображаемая при запуске приложения. Точка (.) в параметре "Имя соединения" означает, что используется текущее соединение с БД.

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

   Номер последней обрабатываемой строки - служит для ограничения количества копируемых строк, и применяется для отладки. Например, если запрос возвращает 100 записей, а "Номер последней обрабатываемой строки" = 10, то будет скопировано только 10 первых строк из результата запроса.

   Количество строк в блоке - количество строк сохраняемых одной транзакцией

Способом "Сохранить из БД в БД" я также пользуюсь, когда необходимо скопировать результат запроса с большим количеством записей. Ограничение количества записей, в этом случае, дает преимущество, перед обычным запросом копирования записей (insert into ... select ...), так как снижается нагрузка на диск, не сильно растет журнал транзакций и не используется база tempdb (если "Количество строк в блоке" оптимальное).

Преимущества и применение ImportExportDataSql

Приложение ImportExportDataSql постоянно помогает мне в работе. С помощью него удобно переносить данные из одной БД в другую.

В коде встроено множество проверок, чтобы достаточно быстро можно было понимать на какой строке возникла ошибка при импорте CSV файла или Excel.

Можно загружать большие CSV файлы (больше 1Гб) и добавлять свои поля, которых нет в CSV. Отсекать ненужные поля из CSV, не загружая их в БД.

Скрипты при выгрузке в SQL формат дополнены различными проверками, чтобы при выполнении скрипта на другой базе все ошибки отображались в одной таблице, а не списком ошибок на панеле "Messages" в SQL Server Management Studio.

С помощью типа обработки "Сохранить конфигурацию БД в SQL" и командной строки я автоматизировал создание резервных копий джобов (jobs), репликаций и других объектов БД, чего нельзя сделать стандартными способами.

Заключение

Используя язык C# и класс SqlBulkCopy можно существенно сократить время выполнения запроса, в котором используется Linked Server.

Ссылки

Скачать ImportExportDataSql

Статья с подробным описанием ImportExportDataSql

Статья "Быстрое чтение CSV в C#", в которой рассказывается о недостатках "bcp"

Сообщество VK, для желающих пообщаться с автором

Если вы работаете с сайтом, который постепенно растет, - увеличивается количество товаров, трафик с рекламы - то рано или поздно придется перейти в режим работы highload, высоких нагрузок на сервер. Но что делать, если ваш сайт не растет, а сервер все чаще не выдерживает, и происходит блокировка данных? Именно с этой проблемой мы столкнулись, дорабатывая сайт для интернет-магазина светового оборудования с ассортиментом более чем 100 000 товаров.

Исходная ситуация

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

Поиск проблемы

Мы провели аудит настроек сервера и сайта, разделив работы на два этапа: анализ back-end и front-end, и обнаружили низкую скорость загрузки страниц на back-ende - порядка 80 секунд на самых посещаемых страницах, что в итоге приводило к существенному снижению конверсии.

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

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

Решение

Шаг 1. Настройка баз данных

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

Шаг 2. Смена типа хранения на InnoDB

Почему мы выбрали InnoDB?

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

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

Также была произведена оптимизация работы самой базы данных InnoDB. Например, были оптимизированы параметры:

# InnoDB parameters

innodb_file_per_table

innodb_flush_log_at_trx_commit

innodb_flush_method

innodb_buffer_pool_size

innodb_log_file_size

innodb_buffer_pool_instances

innodb_file_format

innodb_locks_unsafe_for_binlog

innodb_autoinc_lock_mode

transaction-isolation

innodb-data-file-path

innodb_log_buffer_size

innodb_io_capacity

innodb_io_capacity_max

innodb_checksum_algorithm

innodb_read_io_threads

innodb_write_io_threads

Промежуточные результаты

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

Это в свою очередь привело к уменьшению потребляемой оперативной памяти.

Шаг 3. Перенастройка Nginx и установка модулей кэширования brotli, pagespeed, proxy_buffering

Nginx позиционируется как простой, быстрый и надежный сервер, неперегруженный функциями. Уже длительное время Nginx обслуживает серверы многих высоконагруженных российских сайтов, например, Яндекс, Mail.Ru, ВКонтакте и Рамблер. Для улучшения производительности при использовании дополнительных серверов, Nginx поддерживает буферизацию (proxy_buffering) и кеширование (proxy_cache), чем мы и воспользовались.

Не обошлось и без курьезов настроек Nginx. У клиента был обычный интернет-магазин с товарами, тогда как настройки буферизации, которые мы обнаружили во время аудита, позволяли ему быть чуть ли ни стриминговым сервисом. Мы существенно уменьшили значения в параметре client_max_body_size, что в совокупности с перенастройкой Nginx еще больше снизило потребление памяти.

Шаг 4. Оптимизация настроек PHP-FPM и Memcache и отключение Apache

PHP-FPM нередко используется в паре с веб-сервером Nginx. Последний обрабатывает статические данные, а обработку скриптов отдает PHP-FPM. Такая реализация работает быстрее, чем распространенная модель Nginx + Apache.

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

Необходимым шагом стал перевод работы PHP-FPM на unix socket. Зачем это понадобилось? Nginx сам по себе довольно быстрый веб-сервер, однако самостоятельно он не может обрабатывать скрипты. Для этого необходим бэкенд в виде PHP-FPM. Чтобы вся эта связка работала без потери скорости, мы использовали unix socket способ подключения к PHP-FPM, позволяющий избегать сетевые запросы и дающий значительный прирост в скорости работы сайта.

Результаты работ

1. Время отклика главной страницы уменьшилось с 24 секунд до чуть более 3 секунд, внутренних до 5-8 сек.

2. Уменьшилось потребление серверных ресурсов.

3. Стабилизировалось поведение сервера - он перестал зависать.

4. Глубина просмотров увеличилась на 30%, и как следствие, это дало улучшение в SЕО, а также последующих продаж: растут поведенческие показатели => растут позиции сайта в выдаче => растет трафик => растут продажи.

5. Клиенту были даны рекомендации по оптимизации front-end части сайта для ускорения работы сайта. Например:

• оптимизировать графики и настройку выдачи изображений в формате webp;

• настроить lazyload-загрузки данных;

• вынести все некритические для отображения страницы скрипты в конец страницы.

Вывод

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

В последнее время всё чаще появляются статьи о производительности российских процессоров Эльбрус на различных задачах. Тема криптографии пока что остаётся за кадром, хотя в разное время были упоминания то о высоких возможностях Эльбруса (некий ГОСТ лучше в 9 раз на Эльбрус-4С, чем на Intel Core i7-2600), то о плохой оптимизации компилятора и, соответственно, крайне низкой скорости реализованных алгоритмов (Кузнечик в 100 раз медленнее, чем на Intel?). Предлагаю наконец разобраться, что может Эльбрус, на примере двух ГОСТ алгоритмов симметричного шифрования.

Чтобы статья не вышла слишком большой, будем считать, что читатель имеет общее представление об архитектурах процессоров, в том числе знает об Эльбрусе. Если же нет, на сайте разработчика (компании МЦСТ) есть отличное руководство по программированию и книга об архитектуре в целом. Именно с этих материалов и началось моё знакомство с Эльбрусами. Также отмечу, что в современных процессорах очень много различных механизмов и особенностей, так что в статье буду касаться только тех, которые, на мой взгляд, важны при реализации выбранных алгоритмов.

Что может предложить архитектура Эльбрус

Для выполнения арифметических операций у Эльбруса есть 6 АЛУ (арифметико-логических устройств), способных выполнять операции параллельно. Начиная с версии 5 архитектуры появилась поддержка упакованных (SIMD) инструкций над 128-битными регистрами.

Для хранения промежуточных результатов присутствует большой регистровый файл: суммарно в процедуре можно использовать более 200 (64-битных) регистров общего назначения. Для SIMD вычислений используются те же самые регистры, а не отдельные, как это часто бывает. Соответственно, с 5 версии архитектуры все регистры стали 128-битными.

Задачу симметричного шифрования можно отнести к потоковой обработке массива данных. Для таких ситуаций в Эльбрусе есть механизм асинхронной подкачки данных из памяти APB (Array Prefetch Buffer). Использование этого механизма позволяет вовремя подгружать данные из памяти, не теряя время на кэш-промахи.

Выбор реализаций

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

Правда, о производительности ГОСТ алгоритмов обычно говорят только в контексте семейства x86-64, другие архитектуры мало кого интересуют. Но это не беда: мне показалось, что при знании команд ассемблера x86-64 ознакомиться с набором целочисленных и логических инструкций Эльбруса проще, чем, скажем, с ARM-овым. То есть прослеживаются определённые параллели, особенно, в области SIMD инструкций, и даже прямые аналоги. В остальном, конечно, у них нет ничего общего.

Итак, для Магмы известна эффективная реализация режимов, допускающих параллельную обработку блоков, то есть когда несколько блоков могут шифроваться независимо друг от друга. Это, например, режимы ECB, CTR, MGM. При этом скорость конкурирует с AES, для которого на x86-64 есть аппаратная поддержка. Реализация заточена именно под параллельную обработку, в случае последовательной (режимы с зацеплением) используются другие подходы. Мне интересно добиться максимальной скорости, поэтому я ограничился только случаем параллельной обработки.

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

Тестовые машины

Магма

В случае x86-64 быстрая реализация Магмы опирается на использование расширений AVX и AVX2. При этом учитывается наличие в процессоре нескольких АЛУ и возможность параллельного исполнения до 3 векторных инструкций за один такт. Естественно, планирование параллельного исполнения остаётся на откуп процессора.

В случае же Эльбруса есть возможность явно распланировать параллельное исполнение. Опуская некоторые детали, можно считать, что на 3 и 4 поколении возможно исполнить 6 целочисленных векторных операций над 64-битными регистрами, а начиная с 5 поколения 4 векторных операции уже над 128-битными регистрами.

Для Эльбруса я написал собственную реализацию Магмы. Она использует те же идеи, что и исходная под x86-64, но при этом адаптирована под другой набор инструкций. Рассматривал перспективу написания на ассемблере и даже пробовал, но довольно быстро осознал, что ассемблер у Эльбруса достаточно сложный в плане программирования на нём (например, есть много нюансов по размерам задержек и зависимостям инструкций, которые тяжело учесть вручную). При этом оптимизирующий компилятор делает свою работу действительно хорошо: переставляет инструкции в рамках большого окна и при подборе опций компиляции выдаёт плотность кода, которая не отличается от теоретических оценок на количество инструкций и тактов. Так что я остановился на реализации на языке Си с использованием intrinsic функций для доступа к некоторым инструкциям процессора.

Для измерения скорости был выбран режим ECB. Обычно именно он (или даже его упрощения) используется при сравнении производительности, а скорость других режимов можно оценить на базе полученных результатов, отличия несущественны. Речь идёт о реализации базового алгоритма шифрования, поэтому накладные расходы от смены ключа также не учитываются. Объём данных для замера порядка 1 ГБ. Естественно, шифрование на одном ядре. Для многоядерной машины можно умножить результат на количество ядер и получить близкую к реальности оценку скорости. По крайней мере, во всех сравнениях я видел именно такую зависимость. Полученные результаты в таблице ниже:

Здесь под выровненными данными подразумевается выравнивание по границе 8 байтов для E2Kv3/E2Kv4 и 16 байтов для E2Kv5/E2Kv6. При наличии такого выравнивания (на версиях до 6) работает механизм APB и данные для шифрования эффективно подкачиваются из памяти. При этом с версии 6 APB уже не требует выравнивания данных, поэтому при любом расположении данных достигается максимальная скорость. Для невыровненных данных на предыдущих версиях архитектуры я не провёл достаточно исследований, так что значения в этом столбце таблицы можно считать нижней границей.

Для сравнения приведу результаты из статьи с описанием базовой реализации на Intel Core i3-7100 @ 3.9 ГГц. При использовании AVX 458 МБ/с, 8.1 такт/байт; AVX2 1030 МБ/с, 3.6 такт/байт. Так что по абсолютной скорости Эльбрус достаточно близок к современным процессорам Intel (это при значительной разнице в тактовой частоте!) и превосходит x86-64 с AVX в тактах более чем в 1.5 раза (для 3 и 4 поколения), а x86-64 с AVX2 в 1.3 раза (для 5 поколения).

Кузнечик

По сравнению с Магмой, структура Кузнечика является более сложной. Несмотря на то, что удалось декомпозировать нелинейное преобразование S, техники реализации, основанные на широком использовании SIMD-инструкций, пока что отстают от "классической" реализации со склеенным LS (линейным и нелинейным) преобразованием и таблицей предвычислений размером 64 КБ (упоминается в статье под именами с LS или более простое описание на Хабре).

В случае x86-64 Кузнечик эффективнее всего реализуется с использованием AVX-инструкций (удобно работать со 128-битными регистрами, так как длина блока и размер значений в таблице равны в точности 128 битам). При этом для вычислений адресов в таблице не удаётся воспользоваться эффективной адресацией Scale-Index-Base-Displacement (именование из статьи), так как в качестве Scale нужно значение 16, а максимально возможное 8. На Эльбрусе можно ожидать конкурирующих результатов за счёт большого кэша L1d (64 КБ) и наличия 4 АЛУ, обеспечивающих произвольный доступ к памяти (насколько мне известно, у абсолютного большинства процессоров x86-64 2 порта для загрузки данных).

Как и в случае с Магмой, для Кузнечика я написал отдельную реализацию на Си под Эльбрус, чтобы добиться максимальных результатов. Начиная с 5 версии архитектуры я явным образом использовал тип __v2di (см. e2kintrin.h в составе компилятора), чтобы быть уверенным, что получится использовать регистры как 128-битные.

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

Итак, в случае строго последовательной обработки данных:

Для сравнения результаты из статьи (лучшие из опубликованных) на Intel Core i7-6700 @ 4 ГГц 170МБ/с, 22.4 такт/байт. В отличие от Магмы, можно говорить о сопоставимой абсолютной скорости и преимуществе в тактах более чем в 2 раза.

В таблице заметен интересный момент: результаты ощутимо колеблются среди последних 3 версий Эльбруса. Такое поведение я заметил буквально недавно и начал обсуждение с коллегами из МЦСТ, так что есть надежда, что результаты удастся немного улучшить при доработке компилятора.

С параллельной обработкой ситуация намного интереснее:

И традиционное сравнение с Intel Core i7-6700 @ 4 ГГц: на нём достигается 360 МБ/с, 10.6 такт/байт. В отличие от случая последовательной обработки, у E2Kv3 и E2Kv4 преимущество Эльбруса не такое большое, предположительно из-за того, что реализация обработки нескольких блоков вместе обладает более высокой степенью параллельности и планировщику на x86-64 легче справиться с выявлением независимых операций. А вот появление у 5 поколения Эльбруса 128-битных регистров и загрузок из памяти позволяет ему сохранить преимущество в тактах более чем в 2 раза.

Сравнивать E2Kv6 с i7-6700 оказалось несолидно, поэтому я взял ассемблерную реализацию режима ECB и провёл собственный замер. В статье с описанием результатов на i7-6700 данные шифруются на месте, без работы с памятью, поэтому у честного режима ECB результат чуточку хуже: на самом мощном из доступных мне процессоров Intel Core i7-9700K @ 4.7 ГГц вышло 411 МБ/с, 10.9 такт/байт. Эльбрус оказался быстрее, обеспечивая преимущество в тактах в 2.5 раза.

Заключение

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

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

С другой стороны, сложившаяся похожесть ряда инструкций упрощает разработку и оптимизацию под Эльбрус. Можно сказать, что эта статья предлагает простой способ портирования и оптимизации алгоритмов под Эльбрус: достаточно взять хорошо зарекомендовавший себя на Intel/AMD алгоритм и немного адаптировать его под Эльбрус. Я искренне верю, что в результате практически любой алгоритм должен работать по крайней мере не хуже, чем в разницу тактовых частот.

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

P.S.

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

Несмотря на то, что для получения описанных результатов мне удалось разобраться с Эльбрусом на основании только открытой информации и документации к компилятору, я хочу выразить благодарность сотрудникам МЦСТ, в особенности, Александру Трушу, за ответы на периодически возникавшие у меня вопросы и, конечно, за предоставление удалённого доступа к новым процессорам.

Современные системы искусственного интеллекта подходят к решению таких задач, как распознавание объектов на изображениях и прогнозирование трёхмерной структуры белков, как прилежный студент готовится к экзамену. Тренируясь на многих примерах решения аналогичных задач, они со временем сводят к минимуму собственные ошибки и в конце концов добиваются успеха. Но приведённый пример лишь частный случай и лишь одна из известных форм обучения. К старту курса "Machine Learning и Deep Learning" делимся переводом статьи о том, как в DeepMind создали многоагентную систему при помощи нового подхода EigenGame, то есть компромисса между чистой оптимизацией и динамической системой.

Обучение также происходит при взаимодействии и играх с другими людьми. Перед человеком могут вставать чрезвычайно сложные проблемы, и решить их в одиночку ему вряд ли удастся. DeepMind попыталась решать проблемы с использованием определённых игровых приёмов, и у неё это прекрасно получилось она обучила агентов ИИ играть в Capture the Flag, а один из её агентов даже набрал гроссмейстерскую норму в Starcraft [мы писали об этом вчера, в статье о том, как StarCraft II может помочь экологам]. Это заставило нас задуматься, сможет ли теория игр помочь в решении других фундаментальных проблем машинного обучения.

Сегодня на ICLR 2021 (Международной конференции по обучающим представительствам) мы представили исследование "EigenGame: метод PCA как равновесие по Нэшу", получившее награду за лучшую публикацию (Outstanding Paper Award). В нём мы описали новый подход к решению старой проблемы: представили метод главных компонент (PCA), тип задачи о собственных значениях как конкурентную многоагентную игру. Такую игру мы назвали EigenGame. Метод PCA обычно трактуется как задача оптимизации (или проблема одного агента); однако мы выяснили, что, если применить многоагентный подход, можно разрабатывать новые идеи и алгоритмы, использующие современные вычислительные ресурсы. Применяя многоагентный подход, мы научились масштабировать огромные наборы данных, обработка которых ранее занимала бы слишком много времени и ресурсов, и теперь предлагаем альтернативный подход к проведению будущих исследований.

Метод PCA как равновесие Нэша

Впервые описанный в начале 1900-х годов метод PCA представляет собой давнюю технику, позволяющую осмыслить структуру крупномасштабных данных. В настоящее время данный подход повсеместно используется в качестве средства, обеспечивающего первый этап работы конвейера обработки данных и позволяющего с лёгкостью кластеризовать и визуализировать данные. Данный метод также может оказаться полезным инструментом для обучения низкоразмерных представлений функциям регрессии и классификации. Со времени изобретения метода PCA прошло уже более века, но до сей поры он не утратил своей актуальности.

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

Во-вторых, метод PCA имеет много общего с множеством важных инженерных методов и алгоритмов машинного обучения, в частности с методом разложения по сингулярным значениям (SVD). Благодаря правильно выбранному подходу к применению метода PCA наши идеи и алгоритмы стали широко применяться во всех областях машинного обучения.

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

В игре EigenGame каждый игрок управляет собственным вектором. Игроки увеличивают свой счёт, объясняя дисперсию в данных, но получают штраф, если слишком близко "подходят" к другим игрокам. Мы также устанавливаем иерархию: игрока 1 волнует только максимизация дисперсии, в то время как другие игроки также должны беспокоиться о том, чтобы не "подходить" близко к игрокам, стоящим выше их в иерархии. Такое сочетание поощрений и наказаний определяет полезность каждого игрока.

С помощью надлежащим образом определённых Var и Align можно показать, что:

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

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

Данное свойство независимости одновременного восхождения имеет особенную важность, так как позволяет распределить вычисления по десяткам TPU в Google Cloud, обеспечивая параллелизм данных и моделей. Соответственно, наш алгоритм может адаптироваться к данным действительно крупного масштаба. Для наборов данных из сотен терабайт, содержащих миллионы признаков или миллиарды строк, EigenGame находит главные компоненты за несколько часов.

Полезность, обновления и всё, что с ними связано

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

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

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

EigenGame реализует конкретный пример разработки решения задачи машинного обучения в качестве выхода большой многоагентной системы. В целом разработка задач машинного обучения как многоагентных игр представляет собой сложную проблему разработки механизмов; однако для решения задач машинного обучения исследователи уже используют класс игр с нулевой суммой для двух игроков. В частности, успех генеративных состязательных сетей (GANs) как подхода к генеративному моделированию вызвал интерес к взаимосвязи между теорией игр и машинным обучением.

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

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

Более подробная информация приведена в нашей работе EigenGame: метод PCA как равновесие по Нэшу и последующей работе EigenGame Unloaded: когда играть лучше, чем оптимизировать. Данная запись в блоге основана на совместной работе с Туром Грейпелом, руководителем исследовательской группы в DeepMind и заведующим кафедрой машинного обучения в Университетском колледже Лондона.

Машинное обучение продолжает развиваться, приобретая гибкость, необходимую для решения проблем всё более широкого спектра, а значит её проблемы и решения будут актуальны ещё долгое время по меркам не только быстро изменяющихся информационных технологий, но и других областей знаний, где новые методы будут применяться. Если вам интересна сфера глубокого и машинного обучения, вы можете обратить внимание на курс "Machine Learning и Deep Learning" широкое и глубокое введение в область искусственного интеллекта.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

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

Есть на 20Вт и более - но все их объединяет одно их лучше не покупать, они очень легкие и стоят разумных денег, до 600р.

Конечно же, нам обещают 300часов 30 000часов работы, отсутствие пульсаций, а некоторые производители заявляют о промышленном применении данных ламп, но к этому мы еще вернемся.

Нам обещают: 40Вт, ЦТ 4000k, световой поток 3200лм (http://ecola.ru/catalogue60.html)

На практике: построена лампа на чипе bp2865g, имеет активную мощность ~36Вт, но PF(cosf) ~0,52, т.е. получаем потребление ~55Ва, сразу вспоминаем статью Lamptest (при мощности ламп более 20Вт должен быть PF(cosf) >0,9).

Немного снимков с тепловизора, лампа работает 7 минут, корпус разогрелся всего до 80 градусов.

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

Снова включаем лампу и даем поработать 2 минуты.

Еще через пару минут работы (без рассеивателя).

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

Время провести вскрытие

21 светодиод последовательно, по 2 кристалла в каждом (последовательно), 2 цепочки по 21 светодиоду параллельно. Входные электролиты - 2шт: 400в 4,8мкф рассчитаны на 105 градусов, в закрытой лампе им станет плохо и довольно быстро.

Плата приклеена на герметик к краю пластикового корпуса. Радиатор тип "пробка": +1 к теплоотводу.

Рассеиватель - здесь не сделано ничего для качественного рассеивания света, запишем как: +2 к равномерности рассеивания.

В разных зонах рассеивателя - разная яркость (люксометр прилегает вплотную). Разница в свечении разных зон рассеивателя лампы от 120000лк до 230000, основной световой поток лампы направлен вверх.

После краткого обзора данной "промышленной" лампы осталось понять где ее запихать использовать...

...вы правильно подумали, раз лампа промышленная и у вас нет своего завода, ее надо запихнуть в ЖКУ 250 у дома, благо лампа стоит как днат250 - 350рублей, а производитель нам заявляет, что наша СД лампа - является эквивалентом лампы накаливания 250Вт.

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

На этом, можно сказать, что план по переходу в светлое будущее, в рамках работы одной УК - выполнен.

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

https://minenergo.gov.ru/node/9858

Предисловие

Наконец то я смог перебороть свою лень и написать третью часть. По итогу мы имеем настроенный терминальный сервер, с разграниченными доступами к данным и списками разрешенных программ. В данной части закончим тонкую настройку рабочих столов пользователей, как и обещал рассмотрим Установку, Настройку, и оптимизацию 1С, а так же разграничение доступа к БД. Приступим.

Очищаем рабочий стол от лишних ярлыков

Создадим Групповую политику с названием "Очистить рабочий стол" и свяжем ее с подразделением в котором расположены пользователи нашего сервера

Зададим параметры политики > Конфигурация пользователя > политики > административные шаблоны > Меню Пуск и панель задач там находим Скрыть общие группы программ в меню "Пуск"

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

Размещаем на рабочем столе пользователя необходимые ярлыки приложений

Создадим Групповую политику с названием "Публикация ярлыков" и свяжем ее с подразделением в котором расположены пользователи нашего сервера

Зададим параметры политики > Конфигурация пользователя > политики > Настройка > Конфигурация Windows > Ярлыки > ПКМ создать > ярлык

Заполняем открывшуюся форму, Данные можно скопировать с существующего ярлыка, нажав по нему ПКМ и выбрав свойства, в поле "Размещение" выбираем Рабочий стол

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

Очищаем содержимое Меню ПУСК и задаем начальный макет

Создадим Групповую политику с названием "Настройка Меню Пуск" и свяжем ее с подразделением в котором расположены пользователи нашего сервера

Зададим параметры политики > Конфигурация пользователя > политики > административные шаблоны > Меню Пуск и панель задач > выбираем "Очистка списка недавно использовавшихся программ для новых пользователей" и переводим параметр в состояние Включена

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

Создадим макет

Заходим на наш сервер под локальным администратором и настройте вручную нужный вид макета начального экрана, после чего запускаем PowerShell под правами администратора и выполняем команду Export-StartLayout -Path d:\123.xml где в параметре path указываем путь который мы задали ранее в политике

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

Оптимизация 1С

Включаем высокую производительность

Так как 1с любит работать на 1м ядре то крайне зависима от производительности этого ядра, от сюда и такая любовь к высокочастотным процессорам.

идем Пуск > панель управления > оборудование > электропитание > выбираем высокая производительность

Отключаем DFSS для нормальной работы 1С

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями) чтобы повысить производительность 1С:Преприятие 8 в ряде случаев. На момент написания заметки платформа может неудачно взаимодействовать с Dynamic Fair Share Scheduling. Одним из таких признаков может быть долгое открытие конфигуратора в терминальном сервере. Предположительно эта служба Dynamic Fair Share Scheduling думает что 1С:Предприятие потенциально окажет негативное влияния сессией текущего пользователя, захватившего большое количество вычислительных ресурсов, на сессии других пользователей. Служба старается предотвратить чрезмерное использования например дисков одним пользователем, пытаясь организовать равномерное распределение дисковых операций I/O между сессиями.

Чтобы выключить балансировку ресурсов надо выполнить следующие шаги:

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

(gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices").enabledfss

1 включено, 0 выключено.

Если получаем 0, то дополнительно действий не требуется.

Шаг второй. Если предыдущий шаг вернул 1, то продолжаем. После чего открываем реестр windows (regedit) и меняем в следующих ветках некоторые значения:*1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System параметр EnableCpuQuota на 0.

2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk параметр EnableFairShare на 0. Этот параметр особенно сильно влияет.

После этого конфигуратор может открываться значительно быстрее в терминальном сервере. В реально произошедшем в нашей практике случае скорость открытия конфигурации с 40 секунд изменилась до 10 секунд (при наличии кэша конфигурации)

Для этого выполним команды

Set-Itemproperty -Path Registry::"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System\" -name EnableCpuQuota -Value 0  

Set-Itemproperty -Path Registry::"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk\" -name EnableFairShare -Value 0

после чего проверим

Get-Itemproperty -Path Registry::"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System\" -name EnableCpuQuota

Get-Itemproperty -Path Registry::"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk\" -name EnableFairShare 

Результатом должен вернуться 0

Это 2 основных пункта которые влияют на производительность 1с, осталось нам научиться понимать где узкое горлышко производительности

Мониторинг Загрузки сервера

в работе сервера с 1с как показала практика основным показателем является средняя длина очереди диска и загрузка ЦП

Смотрим очередь диска

Заходим Управление компьютером > Производительность > Средства наблюдения > Системный монитор > Добавить > выбираем "Физический диск" > средняя длина очереди диска > выбираем диск на котором лежат базы
Нормальным режимом работы является очередь не превышающая значения 1, все что выше уже будут заметны подтормаживания, при значениях выше 2.5 работа в 1 с становится не комфортной.

За данным параметром крайне важно следить так как высокая очередь на диск тянет за собой высокую загрузку ЦП (которому приходится ждать пока диск ответит)

Формирование списка баз 1С, для пользователей

Будем использовать уже заезженный метод формирования списка на основе NTFS прав, но внедрим немного своего

первым делом определимся с местом где будут лежать файлы запуска БД 1С и укажем путь до этого места, пусть это будет d:\access\1cestart.cfg

Откроем файл C:\ProgramData\1C\1CEStart\1cestart.cfg

и добавим в конец файла строку "CommonCfgLocation=d:\access\1cestart.cfg" после чего сохраним

Далее нам необходимо скачать powershell script отсюда

на 160 строке указываем путь до расположения файловых баз 1с

на 163 задаем путь до подразделения домена в котором будут лежать у вас группы безопасности доступа к БД

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

На этом настройку терминального сервера 1с, можно считать законченно, как итог мы имеем сервер готовый к приему клиентов