Проблемы с modx.pro и документацией.

Последние недели сайт периодически отваливался по таймауту, иногда вместе с соседними проектами на том же сервере. Разобрался. Коротко: за сутки к modx.pro приходит 428 тысяч запросов при живой аудитории меньше тысячи человек в неделю. Расскажу, кто их делает и что с этим сделано.

Сколько нас на самом деле

Живых посетителей меньше тысячи в неделю. Всё остальное — роботы. Примерно четыре пятых трафика.

Кто ходит

В сентябре первое место занимал ClaudeBot: 226 тысяч запросов в сутки, из них 220 тысяч на /all. При двадцати пяти тысячах заметок это девять полных обходов ленты за день. Закрыл его в robots.txt, помогло.

К октябрю на его место пришли двое других:

• Claude-SearchBot — 85 тысяч запросов, 77 тысяч из них на /users;
• Reflectionbot — 40 тысяч, 32 тысячи на /users.

Вместе около трети суточного трафика.

Почему robots.txt их не поймал

Потому что Claude-SearchBot — это не ClaudeBot. Другой токен. Закрыв одного поимённо, я не закрыл никого больше.

Схема оказалась проигрышной в принципе: каждый новый обходчик приходит с полным доступом, а узнаём мы о нём по нагрузке. Поэтому логику перевернул — теперь тяжёлые листинги закрыты для всех по умолчанию, а доступ выдан поимённо Яндексу, Google и Bing.

И отдельная дыра в правиле

В старом файле стояло Disallow: /users/ — со слешем на конце. Такое правило закрывает /users/ivan, но не закрывает /users и /users?page=2: сопоставление идёт по префиксу пути, а путь здесь без слеша.

То есть список пользователей с пагинацией не был закрыт вообще ни для кого. Именно его оба робота и выгребали.

Почти половина трафика была мусором

Самая неожиданная находка. В логах нашлись запросы такого вида:

GET /comments?page=12&MODSESSID=deac0757594052bce6484cfeca71d779

Идентификатор сессии в адресе. Таких запросов за десять часов набралось 89 775 — 47% всего трафика, и 36 тысяч уникальных идентификаторов.

Сайт давно не отдаёт таких ссылок, проверил: в выдаваемом HTML их нет, use_only_cookies включён. Это исторический мусор в очередях роботов — когда-то такие адреса существовали, роботы их запомнили и продолжают долбить по своим спискам.

Каждый такой запрос доходил до PHP, собирал полную страницу и заводил новую сессию в базе. Теперь nginx отдаёт на них 301 на чистый адрес, не доводя до PHP.

Почему ложились все сайты сразу

Это выяснилось ещё в сентябре. Apache обслуживает посетителей ограниченным числом процессов — по одному на соединение, всего 150. Когда свободные кончаются, остальные ждут в очереди и в итоге получают таймаут.

Так вот, больше половины этих процессов простаивало. Браузер давно всё забрал и ушёл, а соединение продолжало держать процесс ещё пять секунд — вдруг попросит что-то ещё. Сократил ожидание до двух секунд, и занятость упала со 150 до 26.

А база на сервере общая. Когда она занята, таймаут получают все проекты разом, включая те, к которым нагрузка отношения не имеет.

Что сделано

• KeepAliveTimeout с 5 секунд до 2;
• robots.txt перевёрнут: закрыто по умолчанию, доступ поимённо;
• /all, /users и /comments закрыты без слеша, чтобы покрыть и пагинацию;
• адреса с MODSESSID отдают 301 из nginx, минуя PHP и базу;
• на соседнем проекте заблокирована подсеть, дававшая 82% его трафика;
• поставлен сборщик состояния сервера, чтобы ловить отказы в момент, а не после.

Что дальше

База настроена этом хорошо: попадание в буферный пул 99,9994%, временные таблицы на диск не выплёскиваются ни разу. Проблема не в ней, а в том, сколько её спрашивают.

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

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