Оптимизация и ускорение

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

«Архитектура веб-приложения»

Влад Шевченко, руководитель Backend-практики red_mad_robot

Начав с проблем современной разработки: запуск MVP за 3–6 месяцев — это слишком долго; MVP нужно развивать в цельный продукт, а не переписывать; шеринг знаний между параллельными командами — Влад разобрал типовое веб-приложение со стороны Backend на компоненты и рассказал, как определять зоны ответственности. 

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

Главные выводы из доклада: 

1. Проектирование позволяет увидеть структуру проекта.

2. Архитектура помогает быстрее и качественнее вгружать новых разработчиков в проект.

3. Архитектура даёт возможность запланировать изменения для развития.

Подробнее читай в презентации или смотри видео ниже. 

«Gitflow, или Выжимаем всё из наших процессов»

Кирилл Мусин, java-разработчик red_mad_robot

Доклад Кирилла был посвящён подбору Gitflow под старт проекта и его перестраиванию под изменения по ходу формирования продукта. Имея на старте Atlassian (Jira + Confluence), GitLab CI/CD, 2–4 человека в команде и несколько банковских контуров, ребята поставили амбициозные цели. А именно:

1. Отдельное пространство в репозитории и CI/CD без привязки к устоявшимся банковским процессам и с возможностью выбирать удобный подход.

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

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

О том, как дошли с нуля до MVP и как выглядит финальный Gitflow, — читай в презентации или смотри видео ниже. 

«Неочевидные правила проектирования REST API»

Серёжа Ретивых, ведущий Backend-разработчик red_mad_robot

Выступление Серёжи выросло из его статьи, которую мы публиковали в феврале и собрали больше 18 тысяч просмотров. В докладе практически то же самое — 12 кейсов проектирования спецификации REST API из нашей практики, которые помогут сэкономить время для разработки. И объяснение, почему стоит следовать подходу contract first — писать спецификацию прежде кода. Но теперь ещё и с мемами! 

Подробнее — в презентации или видео ниже.

Делимся железной экспертизой от практик в нашем телеграм-канале red_mad_dev. А полезные видео складываем на одноимённом YouTube-канале. Присоединяйся!

В первом материале из этой серии была объяснена работа механизма Copy‑on‑Write (CoW, копирование при записи). Там были упомянуты некоторые ситуации, в которых при выполнении кода осуществляется копирование данных. В этой статье речь пойдёт об оптимизации, направленной на то, чтобы копирование не ухудшило бы средних показателей скорости работы кода.

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

Избавление от защитного копирования

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

df = pd.DataFrame({“a”: , “b”: })
df2 = df.reset_index()
df2.iloc = 100

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

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

Кроме того, выбор подмножества столбцов DataFrame теперь всегда будет возвращать срез, а не копию данных, как это было раньше.

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

import pandas as pd
import numpy as np

N = 2_000_000
int_df = pd.DataFrame(
np.random.randint(1, 100, (N, 10)),
columns=,
)
float_df = pd.DataFrame(
np.random.random((N, 10)),
columns=,
)
str_df = pd.DataFrame(
“a”,
index=range(N),
columns=,
)

df = pd.concat(, axis=1)

Тут создаётся объект DataFrame с 30 столбцами, с данными трёх разных типов и с 2 миллионами строк. Выполним следующую цепочку методов на этом датафрейме:

%%timeit
(
df.rename(columns={“col_1”: “new_index”})
.assign(sum_val=df + df)
.drop(columns=)
.astype({“col_5”: “int32”})
.reset_index()
.set_index(“new_index”)
)

Если механизм CoW не включён — все эти методы выполняют защитное копирование данных.

Замеры производительности без CoW:

2.45 s ± 293 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Замеры производительности при включении CoW:

13.7 ms ± 286 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

Тут видно улучшение производительности примерно в 200 раз. Я выбрал этот пример специально для того чтобы показать потенциальные преимущества использования CoW. Не каждый метод получит такую же прибавку к скорости выполнения при применении CoW.

Оптимизация копирования, вызванного непосредственным изменением данных

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

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

df.iloc = 100

Копирование инициируется в том случае, если на данные, лежащие в основе датафрейма df, ссылается другой объект DataFrame. Мы предполагаем, что датафрейм имеет n столбцов, в которых содержатся целые числа, то есть — в его основе лежит единственный объект Block.

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

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

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

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

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

Такую систему работы с данными можно напрямую перенести на объекты DataFrame, хранящие данных разных типов. Все объекты Block, которые не были модифицированы, возвращаются в исходном виде, а разделению подвергаются лишь блоки, подвергшиеся непосредственному изменению.

Теперь мы записываем новое значение в столбец n+1 объекта Block с типом данных float64 чтобы создать срез столбцов от n+1 до m. Новый блок будет содержать лишь данные столбца n+1.

df.iloc = 100.5Методы, которые могут работать с данными непосредственно

Операции индексирования, о которых мы говорили, обычно не создают новые объекты. Они модифицируют существующие объекты непосредственно, в том числе — данные этих объектов. Другая группа методов pandas совершенно не притрагивается к данным объекта DataFrame. Один из ярких примеров — метод rename. Этот метод лишь меняет метки объектов. Подобные методы могут использовать механизм ленивого копирования, упомянутый выше.

Есть и ещё одна, третья группа методов, которые, на самом деле, могут выполняться непосредственно на объектах. Среди них — replace и fillna. Их использование всегда приводит к вызову копирования.

df2 = df.replace(…)

Непосредственная модификация данных без вызова копирования приведёт к модификации df и df2, что нарушает правила CoW. Это — одна из причин того, что мы рассматриваем возможность сохранения параметра inplace для подобных методов.

df.replace(…, inplace=True)

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

Итоги

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

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

О, а приходите к нам работать? 🤗 💰

Content-Security-Policy (CSP) – это HTTP заголовок, который улучшает безопасность веб-приложений за счет запрета небезопасных действий, таких как загрузка и отправка данных на произвольные домены, использование eval, inline-скриптов и т.д. В этой статье будет сделан фокус на директиве style-src и ее использование вместе с CSS-in-JS библиотекой emotion.

Кратко о CSP и style-src

Content-Security-Policy заголовок должен быть выставлен в ответе вместе с загружаемой веб-страницей (например, index.html). Это выглядит следующим образом:

Content-Security-Policy: style-src ‘self’

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

• ‘none’ – все стили запрещены

• ‘self’ – разрешены файлы стилей, которые загружаются с того же домена, что и основной документ (страница)

• , например https://example.com – разрешены файлы стилей с этого домена, также допускаются wildcard (*) на месте под-домена и порта

• ‘–‘, например ‘sha256-ozBpjL6dxO8fsS4u6fwG1dFDACYvpNxYeBA6tzR+FY8=’ – разрешены файлы стилей и inline-стили (тег