On Wed, Aug 22, 2007 at 02:44:25PM +0300, Michael Shigorin wrote: >> То есть если по каким-то причинам время выдачи одним апачем >> ответа существенно большое на отдельных страницах, то >> количество бэкендов приходится увеличивать. MS> Угу, но это скорее anti-DoS уже получается. Если у тебя есть страницы которые по каким-то причинам могут сильно тормозить -- то они сами по себе DoS. Соответственно для хостинга, где запросто какой-нибудь умник таки может склепать подобную страницу, подобная настройка сама по себе DoS. Увы :( > >> MinSpareServers 5 > >> MaxSpareServers 20 > >> StartServers 12 > >> MaxClients 12 >> Везет... мне StartServer 50 надо было делать, а MaxClients 100 >> на одном их хостов не хватало... А когда я их увеличил >> оказалось что надо поднимать и в MySQL лимиты. MS> Это у тебя так долго барахлишко тарахтело? Там автор поделия на PHP шибко умный. Это ещё оно быстро работало, после того как я грязно матерясь смотрел на особо долгие запросы и ручками создавал индексы. MS> Я бы попробовал разбросать по разным апачам с разными лимитами MS> на время исполнения скрипта, наверное. И всё-таки держать их MS> не более двух-трёх на процессор, иначе ты всё равно только дольше MS> разрываешь скедулер. Разрывать-то разрываю. Но когда у тебя пускается одновременно 10 запросов каждый из которых выполняется 5 секунд, а параллельно тарахтит ворох запросов, каждый из которых обрабатывается десятки миллисекунд угадай что будет от заниженого MaxClients. > >> и это было близко к оптимуму, то в случае, когда неспешные > >> коннекшны отрабатывает мультиплексирующий nginx, нам гораздо > >> интересней снизить scheduling overhead путём понижения > >> количества процессов, между которыми будет распределяться > >> процессорное время: > >> MinSpareServers 1 > >> MaxSpareServers 2 > >> StartServers 3 > >> MaxClients 4 >> Что-то вроде. Правда логику по которой надо рассчитывать >> оптимум для этих значений я так и не смог продумать. MS> Я ж писал -- по два активных процесса на CPU core, это довольно MS> известное правило оптимальной загрузки при наличии I/O (бишь MS> когда задача не исключительно в CPU и только в него упёрлась). MS> У меня в парах httpd/mysqld активным можно было считать httpd, MS> поскольку он отъедал примерно на порядок больше времени. Ты сначала расскажи что такое "активный процесс" для обычного web-приложения. Особенно с учетом того что часть запросов тормозиться о диск, а часть о процессор. И ты заранее не знаешь какой из них к чему более жручий. А распараллеливать надо исходя ещё и из этого (пока молотят процессор несколько тредов, можно другими несколькими тредами создавать проблемы HDD). При том что для _правильной_ дисковой системы (то бишь SCSI какие) наборот нужно нагружать диск _параллельно_. MS> Это не дисковое I/O, а shm в php-mmcache ;) (кстати, это только MS> мне показалось или и php5-eaccelerator, и php5-xcache в 4.0 MS> скорее прикидываются рабочими?) Ты не забудь что нормальный кэш все-таки обязан сделать stat() на каждый php-шник и все его include'ы, чтобы убедиться что он не обновился. Так что не все так радужно. Вот в случае если у тебя это FastCGI какой действительно не будет лишнего i/o. Вполне возможно. xcache какие-то намеки на работоспособность даже делает :) Но, возможно, это больше намеки чем работоспособность. > >> Т.е. ограничение количества наиболее активных процессов до > >> двух на ядро позволило выиграть примерно 10% латентности по > >> нижней границе и более 50% -- по верхней. >> А вот это бесспорно. nginx отлично справляется с сериализацией >> потоков запросов. Собственно на том самом сайте где то >> установки nginx не справлялось 100 дочек апача, сейчас их >> трудится несколько штук. MS> Так я и говорю -- попробуй _ограничить_ этими несколькими штуками. Дык я-ж говорю -- пробовал. Получается DoS. Помнишь на f.i когда спамили отдельные странички не грузились (по таймауту резались)? Так вот, в те времена я на себе это ограничение и прочувствовал. Из-за нескольких заспамленых страничек f.i ложился целиком и полностью. Потому что несколько человек обращались к ним, и в результате весь остальной сайт был попросту недоступен. У меня есть идея как решить эту проблему, но решать надо не на уровне апача, а на уровне nginx. Чтобы он держал connections pool с сервером фиксированого размера, и имел два таких пула -- один общий, а один для "тормозов". И если попался "тормоз" то переводил соединение в другой пул, а первый -- освобождал. Так по крайней мере DoS'а настройками не будет, хотя и исчезнет возможность защитится от внешнего DoS'а. >> В теории необходимо их выносить и обслуживать отдельным апачем, >> и nginx разруливать по разным апачам обращения к разным >> страницам. MS> Да-да-да-да-да ;-) Интересно, что я ещё написал, не прочитав MS> уже написанное тобой там, чуть ниже? ;-) :) MS> Естественно. Причём какой-нить редкого ума околовнедренец, MS> выключивший кэш на одной-единственной посещаемой странице ради MS> какой-нить своей финтифлюшки, может угробить весь сайт -- MS> наблюдался тут не шибко давно один такой случай со стороны. Кстати в nginx есть ещё одна фича, которую я пока ещё не начал применять но возможно таки начну -- его встроеный SSI. Совместно с предгенерированием части контента может быть тоже весьма интересной штукой. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- Папа! А что означает Format C: Complete?