> Повторю еще раз. Для Фри Вы благодаря МайИсамному мускулю померяли скорость работы (и реакции!) ФС при рэндомном доступе. А то, что база не сильно нагружена - так она и не может...
Не понял фразы "Она и не может"
> Я буду готов говорить о моей или Вашей правоте или неправоте в данном частном вопросе тогда, когда будет КОЛИЧЕСТВЕННАЯ разница
Правильный подход
Точных цифр на руках нет, а без них это просто слово против слова.
> Консерватизм (здоровый) - использование Release
Но не BETA-у же, пусть и 4-ю! Это подход чисто программерский: "вот это... нет это, самый рабочий и крутой модуль"
Улучшение будет идти всегда, а на продакшн будет или Stable или Release, да еще и предыдущей версии
Вот это пример
здорового консерватизма в моем понятии.
>>А без nginx пробовали?
>Было без. LA в пике 50 а то и 100.
После nginx как изменился LA? До eAccelerator. Мне интересно на сколько падает нагрузка при переходе на него.
В тесте есть возможность включать\выключать запрос "вложенных" в страницу элементов, т.е. как раз статики.
> ИОПС!!! Операции в секунду. У дисков есть предел. И он очень невелик. Около 100, кажется.
Чисто ИОПС это не показатель, еще надо:
- average queue (колличество потоков, которые обслуживает носитель в данный момент времени)
- average service time (за сколько в среднем обслуживается запрос на ввод вывод)
- bytes transfered (это чтобы привязать к размеру запросов на ввод вывод)
100 средне статистических iops в БД для диска на сегодняшний день - ничто.
>>> LAN Traffic, pps, In/Out LAN Traffic, Mbps, In/Out
>>Помониторить можно, только там заведомо будет нагрузка не более 5-10%.
>Не надо заведомо. Надо факты.
Это мониторилось. Трансфер с сервера был в пределах 10МБит, подключение - 1ГБит.
О том что сеть мониторилось, в статье написано.
>>при 350МБ базы это не актуально, т.к. нагрузка на дисковую во время тестов была близка к нулю.
>1. Это Вам так кажется.
нет, не кажется. параметры iostat мониторились в процессе тестов. Но не сохранялись для статьи.
>2. Время реакции разное.
физического ввода\вывода не было.
>3. Цифры уже в студию давайте!
Вот активность по вводу выводу с солярис:
bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s
0 88 100 0 2 100 0 0
0 79 100 0 5 100 0 0
0 75 100 0 3 100 0 0
0 102 100 0 3 100 0 0
0 90 100 0 3 100 0 0
0 79 100 0 4 100 0 0
0 91 100 0 3 100 0 0
0 92 100 0 3 100 0 0
0 116 100 0 2 100 0 0
0 89 100 0 5 100 0 0
0 105 100 0 3 100 0 0
ИМХО это практически сон.
Тут видно, что физического ввода нет. Есть совсем мало работы с кэшем ФС.
Если по памяти не помните колонок:
http://www.cs.biu.ac.il/cgi-bin/man?sar+1
> Только очень уж ошибка детсадовская...
Они есть везде
Даже в оракле совсем недавно:
- Патч Х
- Патч Х.1 через небольшой промежуток (исправление перекомпиляции объектов после патча Х)
> Раскладка поменяется. Поменяется, если изначально системы не были в равных условиях, а их-таки поставят в равные.
Да, при настройке FreeBSD она станет в равные условия.
> P.S. Хорошие советы для того и даются, чтобы им никто не следовал.
Ну почему же! Ряд советов действительно полезных.
Но я до сих пор не могу согласиться с НЕОБХОДИМОСТЬЮ установки nginx и eAccelerator для тестов. В продакшн может быть, но
не в тестовую среду. Появляются дополнительные звенья, которые вносят свои возмущения, требуют неоднозначной настройки.
Тем более как я понял под eAccelerator далеко не все работает, и много хостеров живет без него.
Для исключения nginx можно убрать из теста загрузку статики, и предполагать, что тестируется производительность сервера
стоящего за отдельной машиной с nginx, как и делается именно в нагруженных проектах.
> P.P.S. А что - ПОЛНАЯ спецификация тестовой системы - это все-таки тайна?
Не тайна конечно, вот даташит:
http://www.newisys.com/products/4300-e.pdf
Если интересно более подробно тринитевцы расскажут, я не работаю в тринити.
> К моменту повторного теста (пусть он будет!) Вам будет нужно уже использовать 6.1.
Наличие или отсутствие повторного теста зависит не только от меня.
Как минимум нужна машина на несколько недель и активные консультации заинтересованных и знающих людей.
Как максимум время для тестов, его надо реально много. Также нужен специалист по фре, также со временем.
Но полезность повторного теста, для меня весьма сомнительна, т.к. мы
протестируем нового сферического коня в вакууме.
- Изменение версии или производителя компилятора может поменять результаты на 20-40%.
- Разные модели шедулеров, мы не можем однозначно утверждать что для этой нагрузки лучше
тот или иной шедулер, пока не проверим, а проверять долго.
- наличие или отсутствие нормальных драйверов под ту или иную ОС также вносит серьезные возмущения
Этот список можно продолжать до бесконечности, и всегда, абсолютно всегда тест будет неактуален для
реального проекта и надо на проекте делать сайзинг заново.
Будет или нет вторая часть марлезонского балета пока утверждать не берусь.
