Сайты университетов спокойно работают большую часть года и испытывают трудности лишь в несколько особенно напряжённых дней. Причина редко кроется в недостаточно мощном сервере. Дело в том, что в эти дни большинство страниц уже невозможно отдать из сохранённой копии. В этой статье простым языком объясняется, как Drupal сохраняет страницы, что ускоряет CDN, а что нет, и с чего начать, если вы хотите, чтобы сайт выдержал нагрузку.
В марте страница загружается за полсекунды, а в первое утро записи на курсы — за десять секунд. Тот же сайт, тот же код. Изменилось лишь одно: сколько страниц серверу пришлось собрать с нуля в этот день. Ускорение сайта на Drupal сводится главным образом к тому, чтобы уменьшить это число.
Когда сайт университета действительно начинает тормозить?
Большую часть года большинство посетителей не авторизованы. Абитуриенты просматривают образовательные программы, родители открывают страницу контактов, поисковые системы обходят раздел новостей. На все эти визиты можно ответить из сохранённой копии, и сервер почти не нагружается.
В напряжённые дни картина меняется. Значительную долю посетителей теперь составляют авторизованные студенты. Как только человек входит в систему, страница становится персональной, и копия, сохранённая для всех, ему уже не подходит. Сервер начинает одновременно собирать с нуля тысячи страниц.
К этому добавляются ещё два фактора. Количество свободных мест и расписание считываются из другой системы и не могут храниться долго, потому что не должны устаревать. А когда меняется академический календарь или общеуниверситетское объявление, необходимо пересобрать каждую страницу, где выводится эта информация.
Когда все три фактора приходятся на одну неделю, сайт замедляется. Цель не в том, чтобы выиграть несколько миллисекунд в обычный день. Цель в том, чтобы пережить эти дни без сбоев.
Как Drupal сохраняет страницы
Собрав страницу, Drupal сохраняет её копию. Следующий человек, запросивший ту же страницу, получает сохранённую копию, а не ждёт, пока страница будет собрана заново. Это главная причина, по которой сайт на Drupal кажется быстрым, и работает это сразу после установки.
Для неавторизованных посетителей
Это простой случай. Все видят одну и ту же страницу, поэтому одна сохранённая копия обслуживает всех. Страницы программ, новости и контакты отдаются тысячам людей из одной и той же копии, а сервер почти ничего не делает.
Для авторизованных пользователей
Как только человек входит в систему, часть страницы становится только его: его имя, его уведомления, его курсы. Использовать одну копию, сохранённую для всех, уже нельзя.
Drupal решает эту задачу, разделяя страницу на две части. Он по-прежнему сохраняет части, одинаковые для всех, и при каждом визите пересобирает только персональные. Таким образом, заново собирается лишь часть страницы, а не она целиком.
Если и эти персональные части работают медленно, в дело вступает BigPipe. Этот подход изначально разработали в Facebook, а затем Drupal включил его в ядро. Принцип его работы прост: общие части страницы отправляются сразу, а персональные — по мере готовности. В результате посетитель видит, как страница заполняется, а не смотрит на пустой экран. Согласно документации Drupal, BigPipe включён по умолчанию в стандартной установке начиная с версии 8.5, а значит, уже работает на большинстве сайтов.
| Неавторизованные посетители | Авторизованные пользователи | |
|---|---|---|
| Как приходит страница | Из сохранённой копии | Общие части сохранены, персональные пересобираются |
| Нагрузка на сервер | Почти нулевая | Некоторая работа при каждом визите |
| Риск в напряжённый день | Низкий | Именно здесь сосредоточена нагрузка |
Что происходит при изменении контента
Самое сложное в сохранении страниц — не наполнить хранилище, а обновить нужные страницы в нужный момент. На сайте университета одна и та же информация появляется в десятках мест. Имя одного преподавателя одновременно фигурирует в списке кафедры, на странице курса и в новости.
Drupal фиксирует, от какого контента зависит каждая сохранённая страница. Когда этот контент меняется, он обновляет только зависящие от него страницы и не трогает остальные. Изменение одного имени не расходится волной по всему сайту.
Настоящая ошибка здесь — привычка очищать всё после каждой правки. Это заставляет пересобрать весь сайт, и обычно это происходит в самый неподходящий момент. Решение — перестать относиться к этой кнопке как к части ежедневной рутины.
Что ускоряет CDN, а что нет
CDN отдаёт файлы сайта с серверов, распределённых по всему миру, поэтому изображения, видео и шрифты приходят из точки, расположенной рядом с посетителем. На сайтах университетов эти файлы составляют основную часть веса страницы, так что выигрыш реален.
Со стороны Drupal за это отвечает модуль CDN. Одна деталь влияет на планирование: стабильная версия работает с Drupal 9 и 10, а поддержка Drupal 11 всё ещё тестируется. Учреждению, которое уже работает на Drupal 11, стоит знать об этом заранее.
После установки нередко следует типичная ошибка: как только CDN запущена, проблема производительности считается решённой. Но CDN распространяет готовые файлы, а не собирает страницы. Персональная страница, которую видит авторизованный студент, каждый раз собирается на собственном сервере учреждения, и именно там сосредоточена нагрузка в напряжённый день.
ИТ-службы университетов прямо пишут об этом на своих страницах. В руководстве по Drupal одного крупного государственного университета владельцев сайтов предупреждают, что его CDN действует только для неавторизованных посетителей, а авторизованные пользователи полностью её обходят. Стэнфорд идёт в этом разграничении ещё дальше. Его ИТ-служба описывает централизованно управляемую платформу Drupal для сайтов кафедр и подразделений, а также отдельный вариант хостинга для сайтов с высокой посещаемостью. Не все сайты обслуживаются одинаково.
Страницы с данными в реальном времени
Количество свободных мест, расписание и оценки поступают из другой системы и не должны устаревать. Поскольку их нельзя сохранять, это самые затратные страницы сайта.
Помогают три простые меры. Во-первых, отделите элемент с живыми данными от остальной страницы, чтобы каждый раз пересобиралась только эта небольшая часть, а всё вокруг оставалось сохранённым. Во-вторых, задайте ему короткое время жизни вместо нулевого. Количество мест, которому не больше минуты, в большинстве ситуаций вполне приемлемо, а эта минута избавляет другую систему от тысяч запросов. В-третьих, решите, что показывает страница, когда другая система не отвечает. Показать последнее известное значение с отметкой времени лучше, чем не показать ничего.
Работу с данными на таких страницах мы разбирали в статье Интеграция Drupal со студенческой информационной системой.
Множество сайтов на одной платформе
Многие университеты поддерживают десятки сайтов факультетов и подразделений на одной общей установке. Отсюда распространённое предположение: раз сайты делят платформу, то и сохранённые копии у них общие. Это не так. У каждого сайта они свои.
Из этого следуют два вывода. Улучшение, сделанное на одном сайте, само по себе не переносится на остальные. А поскольку сайты на общем сервере делят и его ресурсы, напряжённая неделя у одной кафедры может замедлить страницы другой.
Более широкие плюсы и минусы такой схемы мы рассматриваем в статье Управление сайтами университета с помощью Drupal Multisite. С точки зрения производительности практический вывод таков: определите, у каких сайтов бывают пики нагрузки, и планируйте для них отдельно.
Что измерять
У инструментов измерения есть слепая зона, о которой стоит знать. Большинство из них тестируют сайт без авторизации, а значит, никогда не видят страниц, которые не справляются в напряжённый день. Главная страница может получить идеальную оценку, в то время как экран выбора курсов падает.
Поэтому нужны два взгляда. Первый охватывает страницы, которые посетители видят без авторизации. Метрики скорости Google оценивают именно эту сторону и влияют на позиции в поиске; о них мы рассказывали в статье SEO для Drupal. Второй охватывает страницы, которые видят авторизованные пользователи, и измеряется на сервере, а не в браузере. Как правило, настоящая проблема находится именно там.
Самое полезное измерение у вас уже есть. Серверные логи вашей самой напряжённой недели прошлого года расскажут больше, чем любой инструмент тестирования. В них записано, какие страницы запрашивались в какой час и какие запросы так и не были выполнены.
С чего начать
Хорошо работает такой подход: начать как минимум за месяц до пика и действовать в следующем порядке.
Сначала убедитесь, что настройки кеширования включены. Эта проверка занимает полчаса, но на сайтах, где что-то было отключено, она даёт самый большой эффект из всего списка.
Затем пройдитесь по страницам, которые видят авторизованные пользователи, и определите, какие их части действительно персональны. На большинстве сайтов таких частей меньше, чем ожидалось, а всё остальное можно сделать сохраняемым.
После этого отделите элементы с данными в реальном времени, задайте каждому разумное время жизни и решите, что каждый из них показывает, когда другая система недоступна.
Наконец, проведите тест, смоделированный по самому напряжённому часу прошлого года. Этот тест должен выполняться от имени авторизованного пользователя, иначе страницы, вызывающие проблему, так и не будут проверены.
Параллельно с работой стоит согласовать ожидания. Drupal даёт здесь мощные инструменты, но они не приходят настроенными под ваше учреждение. Решение о том, насколько может устаревать та или иная информация, — организационное, а не техническое, и принимается оно вместе с учебным отделом.
Платформы на Drupal, которые команда Drupal4edu компании Drupart создаёт для таких учреждений, как Университет Едитепе, Университет Истинье и Университет Медиполь, настроены так, чтобы выдерживать эти пики именно таким образом. Подробнее о нашем подходе читайте на странице Drupal в высшем образовании.
Частые вопросы о скорости сайтов на Drupal
Решит ли проблему более мощный сервер?
До определённой степени, но это самый дорогой путь. Большинство страниц, которые не справляются в напряжённые дни, пересобираются потому, что их нельзя отдать из сохранённой копии. Если исправить настройки кеширования, тот же сервер обслужит гораздо больше посетителей. Разумный порядок таков: сначала проверить настройки, сделать сохраняемым всё, что не является персональным, и только потом обсуждать оборудование, если этого всё ещё недостаточно.
Достаточно ли одной CDN?
Нет. CDN распространяет изображения, видео и шрифты, что заметно снижает вес страницы. Но персональная страница, которую видит авторизованный студент, в любом случае собирается на собственном сервере учреждения, и именно там сосредоточена нагрузка в напряжённый день. Если рассматривать CDN как полезное дополнение, а не как основное решение, результат будет более реалистичным.
Можно ли вообще сохранять живые данные, например количество свободных мест?
Ненадолго — можно, и в большинстве случаев нужно. Количество мест, которому не больше минуты, обычно приемлемо, а эта минута не даёт тысячам запросов дойти до другой системы. Главное — выбрать время жизни осознанно и согласовать его с учебным отделом. Не менее важно, чтобы страница не оставалась пустой, когда другая система недоступна, а показывала последнее известное значение с отметкой времени.
Нужно ли очищать кеш после каждого изменения?
Нет, и от этой привычки стоит избавиться. Drupal фиксирует, от какого контента зависит каждая сохранённая страница, и сам обновляет затронутые страницы, когда что-то меняется. Полная очистка заставляет пересобрать весь сайт, и обычно это происходит в самый напряжённый момент. Оставьте эту кнопку для исключительных ситуаций, а не превращайте её нажатие в ежедневный рефлекс.