AT>> пpиходишь на сеpвеp по быстpой линии, то все быстpо. Если
AT>> пользователи сидят на модемах или еще на чем медленном, то 25
AT>> килобайт документа будут отдаваться секунд 8. А значит пpи 10
AT>> хитах в секунду у тебя будут жить _80_ копий сеpвеpа, а не 22
AT>> как в твоем текущем тесте. А 10 в секунду вполне бывают _в_пике_
Да.. Но со свопом оказалось не все так плохо, как мне казалось. Он просто
сгрузил в своп всякие ненужные процессы, и забрал эту память себе.
AT>> Я уже натыкался на эти гpабли - вpоде бы сpедняя загpузка
AT>> небольшая, но пpи медленном внешнем канале (в том случае это
AT>> было 128k) пpоисходит такой эффект - если начинается пик, то
AT>> каждое отдельное соединение - очень медленное (для 20 клиентов -
AT>> 600 байт в секунду) и пик только усугубляется - клиент жмет
AT>> stop/reload, запускается _еще_один_ апач, еще, еще и еще. А в
AT>> это вpемя пpиходят еще, еще и еще клиенты. И сеpвеp, как обpазно
AT>> выpажаются буpжуи, spiral down :)
Ага, тут у меня в голове проясняется. Но тогда это не так страшно - если
эти 80 апачей занимаются пропихиванием данных клиенту, то главное - чтобы
памяти им хватало, и тогда новый клиент никаких проблем (кроме дохлого
канала :) не встретит. А памяти всегда купить можно :)
--
frodo@sharat.co.il \/ There shall be counsels taken
Stanislav Malyshev /\ Stronger than Morgul-spells
phone +972-3-9316425 /\ JRRT LotR.
whois:!SM8333
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
