Помогите выбрать менеджер пакетов

Сейчас как раз смотрю что могёт, а что нет slap-get

статика для БД не повредит больше на 5% запросов это уже кое что

Мы решили по-другому.

1) свои сборки это гемор, задач и так хватало

2) в случае багов даже не пожаловаться в апстрим дистра

3) проще программисту паяльник в зад засунуть чтобы он ускорил на +50% свой php-код.

Собстно мы поступали по третьему сценарию т.к. это самое простое и гарантированно давало прирост. Конечно, когда более простые методы оптимизации исчерпаны тогда может быть и задумались.

Но, честно говоря, 5% это ни о чём. Даже +10% фигня и нивелируются очень большими колебаниями трафика посетителей. Возможно, если бы было 100 серверов то +5% производительности это экономия пяти серваков. А т.к. у нас серваков (исключая резерв) было 3 то эти 5% не приводили к экономии оборудования.

Пардон, увлёкся. Знаю, топик не об этом.

ЗЫ про паяльник пошутил, у нас была дружная комманда.

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

Ты улучшаешь «отзывчивость» или производительность?

Ты же знаешь что прироста меньше чем на 50% юзеры не заметят. Покажи что на сколько улучшилось. Только не трать время на математические тесты, ускорять нужно то чем простые люди пользуются.

А отзывчивость она меряется милисекундами и другими средствами.

Ну раз уж отклоняемся от темы...

[hard offtop]

Ты улучшаешь «отзывчивость» или производительность?

Производительность в первую очередь, во вторую отзывчивость

Вот тебе задачка на досуге конфиг ядра для анализа.

А это параметры, с которыми собрано ядро и модули для atom n270:

-O3 -march=native -mtune=native --param l1-cache-line-size=64 --param l1-cache-size=32 --param l2-cache-size=256 -msahf -mcx16 -fmerge-all-constants -fexcess-precision=fast -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-labels -fno-align-jumps --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216 -funroll-all-loops -fno-gcse -g0 -Wno-all -pipe

А с этими параметрами собраны все программы без исключения:

-O3 -march=native -mtune=native -fomit-frame-pointer -pipe --param l1-cache-line-size=64 --param l1-cache-size=32 --param l2-cache-size=256 -msahf -mcx16 -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=both -fexcess-precision=fast -fmerge-all-constants -fno-gcse -funroll-all-loops -g0 -Wno-all -fvect-cost-model -ftree-loop-linear

А отзывчивость она меряется милисекундами и другими средствами

Да, чуть не забыл... Отзывчивость при 100% загрузке процессора - не реалтайм, но с такими параметрами ядра очень прилично для atom n270:

Parent pid: 1759
 Task 0 (prio 2) (pid 1760):
   Max: 20094 us
   Min: 20030 us
   Tot: 1003220 us
   Avg: 20064 us

 Task 1 (prio 3) (pid 1761):
   Max: 99 us
   Min: 43 us
   Tot: 3611 us
   Avg: 72 us

 Task 2 (prio 4) (pid 1762):
   Max: 84 us
   Min: 17 us
   Tot: 2620 us
   Avg: 52 us

P.S.

Оспаривать ключи нет смысла - каждый выверен до миллиметра.

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

Коли хочешь что-то реальное сравнить - пиши что, но ради этого ставить другие ос не буду - дам только свои цифры для оптимизированной системы на atom n270. Дальше уже сами. И так предоставил пищи для ума уже предостаточно, а по моему вопросу почти в молоко везде отстреляно. [/hard offtop]

чем мерял отзывчивость и как систему нагружал? Посмотрю у себя ради интереса. Сама по себе нагрузка на проц большой задержки не даст. У меня на древней убунте при сборке питона в два потока (два ядра на древнем ноуте) даёт макс. задержку в большинстве случаев по показаниям latencytop <100мс. Убунта 10.10 сильно загаженная, с кучей хлама и забитой оперативкой которая уже залезла в своп и похрустывает винтом.

Измерял стандартно с помощью rt-test. У меня нет акцента на отзывчивость - это второстепенно. Параллельно компилировалось ядро в 3 потока + для верности еще 5 glxgears врубал - твой просто от зависти перегреется))) Нагрузка более чем на однопроцессорный агрегат. А реалтайм не проблема. Можно второе rt ядро поставить и грузится с любого, но производительность просядет.

Господа, неужели под эти условия подходят только гентушные портежи?!

Напиши сам, раз у тебя LFS. А вообще, да.

Думал над этим, но даже портежи не во всем устраивают. Но если буду писать, то так чтобы пакетник сам выдергивал нужную инфу из исходников/бинарников и раскидывал по базе данных. Однако это не один день и не два нужно затратить.