nginx с limit_conn и ajax
 

Добрый день,
на достаточно нагруженном и посещаемом сервере стоит связка ngnix+apache. Ngnix отдает статику, apache разбирается с php.

Поскольку на сайт повадились ходить с многопоточными качалками (да еще криво настроенными), на ngnix было включено ограничение одновременно открытых соединений через limit_conn.

В результате 503 ошибка стала появляться при использовании ajax.

Проблему снизили, увеличив количество одновременно разрешенных соединений с 1 до 3 и вставив задержку перед посылкой ajax, идущей по onchange в текстовом поле. Но не знает ли кто-нибудь более красивого системного решения этой проблемы?

Качалки (многопоточные) вроде шлют за доп. потоком.
Соответственно можно игнорировать такие запросы с Range. Если отдавать 503 в ответ на Range, то качалка не будет работать в многопоточном режиме.

Спасибо, тоже вариант. Хотя, честно говоря, от банального DDOS (который range не пошлет :)) все-таки тоже хотелось бы защититься. У нас не музыка, а просто крупный проект с кучей страниц и большой базой, да еще изображающий из себя полторы тысячи сайтов-поддоменов основного. Мне от одного нашествия роботов-индексаторов на стену лезть хочется :)

А как nginx-у лучше сказать про range/ Погуглила, и вто тут http://forum.nginx.org/read.php?21,5818 получается, что все не так просто и однозначно с этим.

Если запросы в базу не оптимизировать, то и без ддоса будет падать...
Вообще, я бы смотрел в сторону распределения нагрузки (мб тем же nginx'ом). Чего один сервер то насиловать...

Ну про оптимизацию запросов - это как-то естестественно :) Но одно другого не подменяет. А вот сервер - один и тут ничего не поделаешь (пока по крайней мере). Это не от моих пожеланий зависит, тут вопрос скорее финансовый. На самом деле эти псевдосайты - поддомены - не изначальная логика проекта, а переделка под привязку к регионам в яндексе. т.е. получается, этакая фантастика из разряда взбунтовавшихся машин: поисковая система (ну, хорошо, те, кто ее делают :) ) начинает диктовать людям, как им строить показ своей информации, разрабатывать приложения, подбирать железо... Бред :)