[devel] уже давно не о документации

[Anton Farygin]

05.02.2011 23:03, Dmitry V. Levin пишет:
> On Sat, Feb 05, 2011 at 10:47:27PM +0300, Anton Farygin wrote:
>> 05.02.2011 10:09, Aleksey Novodvorsky пишет:
>>> 5 февраля 2011 г. 7:34 пользователь Anton Farygin написал:
>>>> 04.02.2011 22:34, Dmitry V. Levin пишет:
>>>>> Т.н. карманы можно было бы реализовать
>>>>> ещё в прошлом году.  Параллельная
>>>>> обработка заданий была реализована в
>>>>> первую очередь как первый шаг на
>>>>> пути к реализации этих карманов.  Потом
>>>>> мы столкнулись с непреодоленными
>>>>> до сих пор организационно-техническими
>>>>> преградами, о необходимости
>>>>> преодоления которых все
>>>>> заинтересованные, надеюсь, помнят
>>>>> постоянно.
>>>>
>>>> Т.е. - если я правильно понял этот тонкий
>>>> намёк - у нас сейчас тонкое место
>>>> - это отсутствие необходимых серверных
>>>> мощностей и каналов связи.
>>>
>>> Да. Это  главная и застарелая проблема,
>>> которая не решается парой серверов.
>>
>> А каким количеством серверов она
>> решается ?
>
> Это зависит от постановки задачи.  Например, от того, сколько карманов в
> единицу времени требуется обрабатывать одновременно (в среднем и
> максимально).

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

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


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

Кстати, не факт что для карманов нужно предоставлять полную копию 
используемого репозитория, зачастую достаточно показать результаты 
сборки task'а в таком виде, который можно отдать apt'у в качестве 
sources.list.

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