> > > 1) когда ответы маленькие или
> > подавляющее кол-во отдаваемых документов на подавляющем кол-ве сайтов
> > помещаются в 128K (html-ки и картинки-реквизиты странички, равно как и
> > css и внешние js, в общем, все кроме мувиков и больших картинок)
> > сервер с 2G RAM и всего 0.5G kmem уже держит большой трафик при
> > tcp.sendspace=128k + http_accept, неужели в таком случае нет смысла
> > использовать nginx как прокси для апача?
>
> При tcp.sendspace=128k машину с 64k mbuf clusters легко положить парой
> тысяч соединений.
Ну, на tcp.sendspace-128k с kern.ipc.nmbclusters=0 и 2G kmem надо уже
почти 16k соединений с полностью забитым send-буфером.
В таком случае можно и отфильтровать часть этих соединений, или просто
уменьшить tcp.sendspace раза в 2-4 - тогда надо будет ещё найти такой
ботнет чтоб его сложно было отфильровать ))
Да и вообще, есть другие методы доса, хотя дос на kmem весьма веселая
вещь.
А в целом, повторюсь, с sendspace=128k работает отлично при весьма
большом трафе (порядка полсотни Mbit/s вот таких небольших запросов,
часть статика, часть - нет) - так что, nginx получается не нужен тут?
Иногда только приходится повышать kmem до 1G или понижать sendspace до
64k, но там и траф побольше. Апачи живут и здравствуют (http_accept
конечно обязателен).
> > > 2) долгие запросы к базе - число Апачей растёт не из-за клиентов, а из-за
> > > базы, etc.
> > тут все ясно
> >
> > Проводились ли какие-то тесты, на какое время увеличивается время
> > получения контента при включении nginx как прокси между апачем или
> > серфером (при небольшой общей нагрузке на сервер)?
>
> Я не проводил.
Я тоже. Как-нибудь сделаю да выложу сюда. А вообще вопрос интересный,
поскольку использование nginx может привнести отрицательный вклад в
производительность при загрузке сайта.
