Nginx ограничение нагрузки / Техдокументация и мануалы / Alto CMS http://79.174.14.219/comments/879/ ru noreply@altocms.ru noreply@altocms.ru Alto CMS v.1.5.0b1 Nginx ограничение нагрузки (comment #16728) http://79.174.14.219/t/879/#comment16728 http://79.174.14.219/879.html#comment16728 reexistent@gmail.com Fri, 05 Dec 2014 14:30:50 +0300 Nginx ограничение нагрузки (comment #16732) http://79.174.14.219/t/879/#comment16732 http://79.174.14.219/879.html#comment16732 reverty@gmail.com
2. Вы кэшируете всю страницу целиком или только объекты используемые для генерации страницы? Сколько времени генерируется у вас хотя бы главная страница? Или же у вас закэшированный html отдается?

3. Если страница генерируется, даже за 0.1 секунды, вы же понимаете что это довольно ощутимая нагрузка для впс. Если я в 10 закладках поставлю отправлять 50 запросов в секунду? Мой впс может и потянет, но отдавать страницы ооооочень долго.

4.Даже habrahabr использует этот же инструмент. Вы этим сайтом тоже не пользуетесь потому что он отдает 503?]]> Fri, 05 Dec 2014 15:01:52 +0300 Nginx ограничение нагрузки (comment #16736) http://79.174.14.219/t/879/#comment16736 http://79.174.14.219/879.html#comment16736 reexistent@gmail.com 1. А зачем сервису такой пользователь, который делает 20 запросов в секунду? Ну явно не обычный пользователь.
А зачем сервису который можно положить с одного IP вообще думать о высокой нагрузке? Видимо он расчитан изначально на другое.

И сразу второй, зачем севис рассчитанный на 10 юзеров в день кто-то будет ддосить? =) И кто этот человек пользующийся таким МОЩНЫМ инструментом? =)

2. Вы кэшируете всю страницу целиком или только объекты используемые для генерации страницы? Сколько времени генерируется у вас хотя бы главная страница? Или же у вас закэшированный html отдается?

Кеширование в высоконагруженных проектах всегда многослойное — что-то должно кешироваться ну уровне браузера, что-то на уровне веб сервера, что-то на уровне логики, что-то на уровне БД, и т.д.

В контексте Альто, достаточно включить query cache на InnoDB в MySQL чтобы повторные селекты не приводили к повторным обращениям к дисковой подсистеме, а результаты брались из памяти. Даже мемкеш не нужен.

Если задача более сложная, то можно сделать так чтобы например вся главная страница, к которой происходит большинство обращений, бралась из кеша в течении как минимум минуты.

3. Если страница генерируется, даже за 0.1 секунды, вы же понимаете что это довольно ощутимая нагрузка для впс. Если я в 10 закладках поставлю отправлять 50 запросов в секунду? Мой впс может и потянет, но отдавать страницы ооооочень долго.

Пользователи обновляющие страницу создают очень малую нагрузку.

4.Даже habrahabr использует этот же инструмент. Вы этим сайтом тоже не пользуетесь потому что он отдает 503?

Высоконагруженные проекты уровня хабра скажем так чуть более сложную архитектуру имеют.]]> Fri, 05 Dec 2014 16:07:21 +0300 Nginx ограничение нагрузки (comment #16737) http://79.174.14.219/t/879/#comment16737 http://79.174.14.219/879.html#comment16737 reverty@gmail.com
Даже если у сайта аудитория 100 человек, ну можно же банально защититься от одного обиженного человека? Можно. Всего-то две строки в конфиге. Станет ли от этого проекту хуже? На мой взгляд нет.

В контексте Альто, достаточно включить query cache на InnoDB в MySQL чтобы повторные селекты не приводили к повторным обращениям к дисковой подсистеме, а результаты брались из памяти. Даже мемкеш не нужен.
В альто, по крайней мере у меня, наибольшую нагрузку дают не запросы к базе. Вот практически голый сайт с альто у меня генерируется 0.05 секунды, из них обращение к базе и кэшу занимает 0.0015, смешное время. Т.е. эти самый 0.05 с процессор над чем-то трудится. Обрабатывает экшены, ивенты, условия и циклы в смарти. Сколько будет обращений к странице столько процессор и будет заниматься вычислениями и будет нагружен.
Пользователи обновляющие страницу создают очень малую нагрузку.
Давайте проверим. Возьмем хром, откроем ваш сайт и в консоле запустим 
for (var i = 0; i < 2000; i++) {
 ls.ajaxGet("http://yourdomain.ru/", {}, null);
}
Запустим мониторинг, хотя бы top, на сервере и понаблюдаем за нагрузкой. У вас нагрузка не возросла? У меня её отчетливо видно. Правда в других браузерах сайт отвечает, и не всегда задумчиво, но мы видим пожирание ресурсов.

Нет, я ни в коем случае не говорю что это панацея, нет. Просто почему бы и нет. Я в нем вижу больше пользы чем вреда.]]> Fri, 05 Dec 2014 16:37:46 +0300 Nginx ограничение нагрузки (comment #16738) http://79.174.14.219/t/879/#comment16738 http://79.174.14.219/879.html#comment16738 reexistent@gmail.com В альто, по крайней мере у меня, наибольшую нагрузку дают не запросы к базе. Вот практически голый сайт с альто у меня генерируется 0.05 секунды, из них обращение к базе и кэшу занимает 0.0015, смешное время.
Если включен кеш так и будет. Или это вообще пустой сайт, на котором ничего не создается. Посмотрим что случится, когда будут одновременно и инсерты и апдейты и селекты идти.

БД — с наибольшей вероятностью главная проблема. Если конечно не используется апач с префорком. (Тогда и нагрузку создавать не надо достаточно открыть N медленных соединений, заблокировав все ресурсы веб сервера).

Запустим мониторинг, хотя бы top, на сервере и понаблюдаем за нагрузкой. У вас нагрузка не возросла? У меня её отчетливо видно. Правда в других браузерах сайт отвечает, и не всегда задумчиво, но мы видим пожирание ресурсов.

Мой сайт сейчас не на альто, он расчитан небольшую нагрузку. VPS за 500 р в месяц. При 50 одновременных клиентах, и времени загрузки ~0.9-1 (методика loadimpact.com) никакой существенной нагрузки на ЦПУ я не наблюдал, как и деградации сервиса. Если потребуется что-то более серьезное — я начну с анализа трафик модели и узких мест, таки думаю этим местом будет БД, а если точнее — дисковая подсистема по iops.

Самая основная проблема такого фильтра что из под одного IP могут приходить несколько пользователей. Значит надо это закладывать. Если это закладывать, то сама эта идея теряет смысл, а способов ДоСа и ДДоСа в целом куда больше.]]> Fri, 05 Dec 2014 16:49:47 +0300