Re: [room] Linux, FreeBSD, Solaris

["Денис Смирнов" <mithraen@altlinux.ru>]

On Fri, Mar 31, 2006 at 01:50:21PM +0300, Michael Shigorin wrote:

MS> Это с какого перепугу?  Если ты не следил последние лет пять за
MS> тем, как происходит развитие этих ядер по части SMP, то более чем
MS> предсказуемый результат.  BKL, который у нас ещё в 2.2 довольно
MS> сильно изгнали, у них до сих пор местами водится (называется
MS> giant lock, правда).
MS> В контексте того, что основной нагрузкой был таки apache1, а не
MS> mysql или дисковая подсистема.  Бишь даже то, что на фре до сих
MS> пор не могут с тредами разобраться (если не пользовать
MS> линуксовые, тихонько и не выпячиваясь) -- сильно не влияло.

Дисковая и SMP действительно однозначно лучше сейчас в Linux. Но мне
что-то не верится что 256 тредов это существенно для четырехголового
оптерона.

Уперлись во фре они наверняка именно в кривое SMP, но при правильной
настройке там и один процессор справился бы.

Во фре есть kevent, который судя по словам того же Сысоева заметно лучшее
API чем epoll имеет. В смысле меньше syscall'ов для того же результата
нужно. Это раз.

Во вторых, вечно забываю как называется решение, вроде socket filters --
то получения целиком заголовка http-запроса этот самый event сгенерирован
не будет, таким образом, если запрос был GET а не POST, то больше читать
из сокета нам не надо совсем. Одним read'ом читаем весь запрос, генерируем
ответ, отдаем. syscall'ы экономим, однако.

Ещё одна тонкость -- PHP. Часть времени ушло внутри него (напоминаю, что
php читает с диска/из кэша файл при каждом его запуске, если не
используется никаких "ускорителей").

>> Основной вывод этого теста, увы -- "Apache мерзкая дешевая
>> поделка". Но это я и без теста знаю :)
MS> Да ты гонишь.  Там первый :)

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

>> Вот если бы сравнили поставив спереди фронтенд вроде того же
>> nginx (который как минимум на Linux и FreeBSD умеет эффективно
>> использовать новомодные фичи обеих систем), тогда это было бы
>> действительно интересно.
MS> (подумав) nginx бы нагрузки не создавал, т.е. можно считать этот
MS> тест на то, сколько бэкендов выдерживает такая система.

Именно.

Только, насколько я помню, всю жизнь разумное правило было ~4 процесса на
ядро. 4*4*2 = 32. Тест успешно показал, что для солярки это правило не
верно (что, в общем-то, тоже было известно, правда я не ожидал такой
разницы).

>> А человек, ставящий столь нагруженый web-сервер, что ему нужен
>> четырехголовый оптерон без reverse proxy либо ламер, либо
>> немножко не в курсе что нужно сделать, чтобы не выкидывать
>> столько денег впустую.
MS> Он вовсе не простак, почитай сам тест и форум, если интересно.
MS> Ссылка внизу, первые три страницы и два сообщения на четвёртой, 
MS> что были на момент заглядывания -- со стороны автора теста более
MS> чем адекватны.  И фронтэнд он тоже упоминает.

Я не так выразился. Именно _ставящий столь нагруженый web-сервер_, а не
проводящий тест. То бишь ты нашел самое правильное определение "тест
столько бэкендов держит система". Но никак не "какую нагрузку выдержит
web-сервер", просто потому что веб-сервера так не делают :)

Я уточню -- бэкендов на типичном хостинге одного нагруженного сайта без
использования акселераторов. Если бы это был простой виртуальный хостинг,
то заметно большая нагрузка была бы на дисковую подсистему.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
У нас нет пpогpаммного обеспечения, зато есть беспечное
пpогpаммиpование.