- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Пиление конфигов с целью снижения нагрузки привело к тому, что бэкэнд отрубается фронтом после нескольких рефрешей. Для статики ограничение мягче в десятки раз, чтобы всякие смайлики-слайдшоу успевали загрузиться. Всё вроде бы устраивает.
Только сомнение такое: как же роботы? Гугл, Яндекс, Сапа. Пожалуй, больше никого не надо пока.
Надо рассказать, что пилили, как пилили, какими умозаключениями вы пользовались.
madoff, началось с того, что друпаловские сайты стали класть сервер. Разбирательство показало общую неустойчивость к нагрузкам. httpd жрал процессор. Там далеко не всё идеально, ещё буду копать. На данный момент, решил ограничить соединения средствами nginx, а именно, применением limit_req limit_req_zone.
Настройка ограничения для самого фронтэнда на данном уровне моего понимания проблемы устраивает. Т.е. прошёл по всем сайтам, удостоверился, что нет ошибок в загруке статики, сделал запас и на этом усполокоился.
Прокси локейшн получил такой конфиг:
limit_req_zone $binary_remote_addr zone=two:10m rate=2r/s;
limit_req zone=two burst=2 nodelay;
Крутил, чтобы и пользователям было комфортно, всё открывалось, и, в то же время, при серийной загрузке нескольких страниц был отказ. Чего, собственно, добился.
Вот сейчас смотрю в логах, Гугл шастает. Ошибок не выдаёт. Вопрос, хватит ли всем ботам такого? Критичны. само собой, Яндекс и Сапа. Есть бешенные пауки вроде MajesticSEO, которые не понимают директивы в robots, так их я наоборот хочу ограничить, т.к. толку от них нет.
Чувствую, хостеры таким не особо заморачиваются, это одиночкам нужно выжать из железа всё :)
Я так понимаю что фронтенд у вас NGINX ?
И вы ставите ограничение limit_
Смотрите в логах access.log и error.log кому выдается код ошибки 503 (превышен лимит)
И если видите что 503 ошибка выдается поисковым ботам, то повышайте лимиты.
У меня стоят такие параметры
limit_zone limz $binary_remote_addr 10m;
limit_conn limz 10;
limit_req_zone $binary_remote_addr zone=lphp:10m rate=1r/s;
location / {
limit_req zone=lphp burst=10 nodelay;
Боты яндекса и гугла такими лимитами не банятся.
Что касается бота сапы – то он слишком быстрый.
Иногда делает 20-50 запросов в секунду.
Но бот сапы забанить не так страшно, так как он будет запрашивать страницу много раз, пока в конце концов ее не получит.
zexis, да, я примерно это и хотел услышать. Интересно, кто и как живёт с этой дилеммой.
Это у вас общее ограничение, или только на бэкэнд? У меня, как выше писал, отдельно настроено.
На локейшн со статикой я ограничений не ставлю.
Так как к статике запросов может быть очень много, да и нагрузки статика большой не создает.