ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [devel] Сборочница (III): Зачем ускорять?
@ 2018-02-17 17:27 Igor Vlasenko
  2018-02-18  0:01 ` Dmitry V. Levin
  0 siblings, 1 reply; 3+ messages in thread
From: Igor Vlasenko @ 2018-02-17 17:27 UTC (permalink / raw)
  To: devel

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

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

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

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-02-19 15:25 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-17 17:27 [devel] Сборочница (III): Зачем ускорять? Igor Vlasenko
2018-02-18  0:01 ` Dmitry V. Levin
2018-02-19 15:25   ` Igor Vlasenko

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git