From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <mithraen@altlinux.ru> Date: Fri, 31 Mar 2006 22:47:23 +0400 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= <mithraen@altlinux.ru> To: shigorin@gmail.com, =?koi8-r?B?y9XM2NTV0s7ZyiDPxtTP0MnL?= <smoke-room@lists.altlinux.org> Message-ID: <20060331184723.GB7060@localhost.localdomain> References: <20060330182438.GD5173@osdn.org.ua> <20060331084541.GB11510@localhost.localdomain> <20060331105021.GG21465@osdn.org.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20060331105021.GG21465@osdn.org.ua> User-Agent: Mutt/1.5.11 Subject: Re: [room] Linux, FreeBSD, Solaris X-BeenThere: smoke-room@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: =?koi8-r?b?y9XM2NTV0s7ZyiDPxtTP0MnL?= <smoke-room@lists.altlinux.org> List-Id: =?koi8-r?b?y9XM2NTV0s7ZyiDPxtTP0MnL?= <smoke-room.lists.altlinux.org> List-Unsubscribe: <https://lists.altlinux.org/mailman/listinfo/smoke-room>, <mailto:smoke-room-request@lists.altlinux.org?subject=unsubscribe> List-Archive: <http://lists.altlinux.org/pipermail/smoke-room> List-Post: <mailto:smoke-room@lists.altlinux.org> List-Help: <mailto:smoke-room-request@lists.altlinux.org?subject=help> List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/smoke-room>, <mailto:smoke-room-request@lists.altlinux.org?subject=subscribe> X-List-Received-Date: Fri, 31 Mar 2006 18:47:25 -0000 Archived-At: <http://lore.altlinux.org/smoke-room/20060331184723.GB7060@localhost.localdomain/> List-Archive: <http://lore.altlinux.org/smoke-room/> 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ование.