Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
sleep в обработке запроса
- To: nginx-ru@xxxxxxxxx
- Subject: sleep в обработке запроса
- From: drmarker <drmarker@xxxxxxxxx>
- Date: Sat, 5 Aug 2006 23:57:22 +0400
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Y0mMwcsneLOtDiIRmLkPRzAinc5kte3w7kGvosJc6LhJZdVPjoKj0SiHUeH4R63ee7nvxwNVtQkIwVVemXJ978TxnfQ4UBVhQbeusuofBYPHlbg3lj1Fs4l4yV02J9jkMQXhH73EtaVMp79d32R7qTItfMN1NZ0k2IaYDTxerh8=
Привет.
Нужен совет уважаемых гуру.
Есть сайт, с которого качают файлы. Есть ограничение по сессиям. В
случае превышения лимитов выдается 503 service temp unavail. front-end
- nginx, BE - apache2 prefork с mod_fcgid и perl. Разрешить/запретить
сессию решает скрипт на BE, который ходит в mysql.
Вопросов два:
a) поддерживает ли (по опыту, ощущениям, whatever) основная масса
download managers retry-after header?
b) имеет ли смысл перед выдачей 503 делать sleep(), чтобы снизить темп
долбления дятлов с агрессивными download managers?
Скажем, sleep(30). Понятно, что у меня останется висеть процесс на BE,
но зато это снизит общее количество выполнений процессов, выдающих
503. База меньше дергается, то се. И против DoS лучше защиты,
наверное, нет.
Второй путь - забить вообще :)
Третий - забить, но между скриптом и mysql поставить memcached с expire.
Что предпочесть?
И нельзя ли применить какую-нибудь хитрую фичу nginx, чтобы решить эту
проблему как-то изящнее?
|
