Поскольку distcc не может сохранять состояния и просто позволяет отправлять задания и заголовки и разрешать этим серверам использовать только отправленные данные, а также выполнять предварительную обработку и компиляцию, я думаю, что у самого последнего distcc есть проблема с масштабируемостью.
В моей локальной среде сборкикоторый имеет ок.10000 файлов c / c ++ для сборки, я мог сделать только в 2 раза быстрее, чем не использовать distcc (но используя make -j) при наличии 20 серверов сборки.
Как вы думаете, в чем проблема?
Если кто-то достиг масштабируемости более 10 - 20 раз, используя make -j и distcc, пожалуйста, дайте мне знать.
В следующем продукте утверждается, что невозможно масштабировать make -j и distccбыстрее, чем в 5 раз.http://www.electric -cloud.com / products / electricaccelerator.php
Я думаю, что это можно улучшить следующим образом:
- Разрешение серверу distccd поддерживать сеансы
- Привязанные к этим сеансам, они будут кешировать свои собственные каталоги заголовков
- Предварительная обработка будет выполняться по требованию с сервера distccd
- Это будет сделано через библиотеку LD_PRELOADed libdistcc.soкоторый заменит системные / открытые системные вызовы и извлекает заголовочные файлы по сети....
Кто-нибудь делал такие вещи?
Я думаю, что Electric Cloud делает подобные вещи, но я думаю, что у нас есть больше места для оптимизации:
- Серверы должны использовать один и тот же репозиторий исходного кода в очень быстрой сетевой файловой системе.
Мы должны выполнить синтаксический анализ файла сборки и включить параллельный анализ заголовка.
кажется довольно сложным без резкого изменения описаний сборки.
Любые идеи, предшествующий уровень техники, обходной путь приветствуется.