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

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

[Igor Vlasenko]

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

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

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

Моими уважаемыми оппонентами в этом вопросе выступили
Алексей и Дмитрий, которые привели аргументы 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

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

On Sat, Feb 17, 2018 at 07:27:35PM +0200, Igor Vlasenko wrote:
> > Вряд ли мы хотим решать задачу принимать в Сизиф 60*60*24/2==43200
> > транзакций в сутки (в среднем по 2 секунды на транзакцию), это число
> > более чем в 2 раза превышает число исходных пакетов в нынешнем Сизифе.
> > Такая задача сама по себе не выглядит осмысленной.
> 
> Как раз очень даже осмысленная задача. 43200 транзакций в сутки --
> это не ожидаемый трафик, а желаемая пиковая мощность,
> следствием которой является повышение "отзывчивости" сборочницы,
> что приводит к повышению производительности труда ее пользователей.

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

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

При этом достижение средней производительности 43200 транзакций в сутки
не кажется мне актуальной задачей, а достижение пиковой производительности
2 секунды на транзакцию не кажется мне реалистичной задачей.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Igor Vlasenko]

On Sun, Feb 18, 2018 at 03:01:21AM +0300, Dmitry V. Levin wrote:
> Могу предположить, что мы хотим
> - максимально ускорить обработку интерактивных заданий, распараллеливая
>   всё что можно, применяя спекулятивные вычисления, что, конечно, снижает
>   среднюю производительность обработки заданий;
> - увеличить среднюю скорость обработки неинтерактивных заданий.
> 
> При этом достижение средней производительности 43200 транзакций в сутки
> не кажется мне актуальной задачей, а достижение пиковой производительности
> 2 секунды на транзакцию не кажется мне реалистичной задачей.

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

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

-- 

I V