[devel] Сборочница (III): Зачем ускорять?

Сб Фев 17 20:27:35 MSK 2018

Уважаемые господа,

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

В этом письме хочу рассмотреть вопрос, зачем ее надо ускорять.

Моими уважаемыми оппонентами в этом вопросе выступили
Алексей и Дмитрий, которые привели аргументы 2-х классов.

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

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

Начну разбор с 1-го класса возражений.

Более обще,
> Сборка пакета имеет смысл, если она меняет что-то у пользователя. Если
> на стороне пользователя ничего не меняется, то вы создаете
> бессмысленный шум. Но есть большая индустрия "очистки спеков" и т.п.,
> которая, за неимением лучшего, выдается за "разработку". Вы выступаете
> апологетом порочных практик, исходя из примитивно понятых базовых
> показателей. Возможно даже вы делаете это добросовестно.

и более конкретно,
> Очевидно, что публиковать якобы новые сборки пакетов, в которых
> ничего не меняется, не просто не нужно, но и вредно.
[...]
> Слепо пересобирать чужие сборки из-за записи в %changelog'е вида
> - Rebuilt for https://fedoraproject.org/wiki/Fedora_NN_Mass_Rebuild
> не просто не нужно, но и вредно.

По поводу импорта, я уже много писал, не хочу повторяться.
Однако, неужели в других дистрибутивах ни багов не чинят, ни пакетов
не обновляют и не улучшают? В импорт только Mass_Rebuild и попадает?
Да, есть недостаток индивидуального подхода к каждому кусту.
Это как копать картошку трактором,
по сравнению с ротой стройбата с лопатами.

Проблема в том, что нас мало, не тянем мы на роту,
максимум на два взвода. Поэтому, tractor it is.

Другой критикуемый пример -- пересборка python-*
без BR: python-modules-setuptools-tests.
Кто-то предлагал, зачем рубить шашкой все пакеты,
проще сделать хак и забыть.

Вот пример, когда-то сделал хак и забыл, а оно зажило своей жизнью
и начало разрастаться по Сизифу.
https://bugzilla.altlinux.org/show_bug.cgi?id=34535

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

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

Отправлять в Сизиф, а не копить у себя -
это сейчас хорошая, годная стратегия.

Это как "Вы скорбите по тем временам, когда мужчины
были настоящими мужчинами и сами писали драйверы устройств?"

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

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

Что делать, такие времена, такие нравы.

Продолжу разбор по 2-му классу возражений.

2а)
> Понимаете, в чем дело.  Время всё равно уходит, а сборочица всё равно
> простаивает. И показатель несколько тысяч транзакций в сутки всё равно
> не нужен. То есть вы занимаетесь неправильной задачей оптимизации.

"Уже сейчас сборочница иногда простаивает. А если мы сборочницу
оптимизируем, то она начнет простаивать гораздо чаще.
А простаивать неправильно."

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

2b)
> Вряд ли мы хотим решать задачу принимать в Сизиф 60*60*24/2==43200
> транзакций в сутки (в среднем по 2 секунды на транзакцию), это число
> более чем в 2 раза превышает число исходных пакетов в нынешнем Сизифе.
> Такая задача сама по себе не выглядит осмысленной.

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

На эту тему есть хорошая притча.
Приходит сисадмин к директору
с предложением расширить канал доступа в интернет.
Директор посмотрел обоснование и сказал: с таким
трафиком, как у нас, мы не расширять,
а еще в 100 раз ужать канал можем,
чтобы приблизить ширину канала к реальному трафику,
заодно и деньги сэкономим.
Сисадмин сказал: смешивать трафик и ширину канала
(пиковую мощность) некорректно.
Рассмотрим к примеру унитаз.
Трафик у него относительно небольшой,
однако ширину канала у него стараются делать как можно больше.
Да. большую часть времени он простаивает.
Но если в нем появляется трафик, то его нужно
как можно быстрее пропустить через устройство,
для чего к нему и подводят такой широкий канал.

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

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

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

-- 

I V