Как запустить сайт на 2500 страниц на сервере с 1 ГБ оперативной памяти: эксперимент с Astro, Laravel и WordPress
Автор: Константин Матыцын, Senior full-stack разработчик, тимлид
Содержание
Можно ли запустить полноценный сайт с тысячами страниц на очень скромном сервере и при этом сохранить хорошую скорость работы? Решил проверить это на практике.
Вместо привычного WordPress с установленной темой я построил систему, в которой каждый инструмент отвечает за свою задачу. Получилась довольно интересная архитектура, а заодно появился повод проверить, насколько далеко можно зайти в оптимизации без покупки более мощного сервера.
От классического WordPress к современной архитектуре
Раньше сайт работал по классической схеме: WordPress, тема, PHP, база данных и динамическая генерация страниц при обращении посетителей.
Теперь архитектура выглядит иначе:
Astro — генерация статического сайта.
Astro собирает весь сайт в статические HTML-страницы. Сейчас речь идёт примерно о 2500 страницах. Посетитель получает уже готовый HTML, поэтому для отображения контента не требуется запускать PHP или обращаться к базе данных.
Это существенно снижает нагрузку на сервер и позволяет добиться высокой скорости загрузки даже при одновременном посещении сайта большим количеством пользователей.
Laravel — API и динамическая функциональность.
Всё, что действительно должно работать динамически, вынесено в Laravel. Это лайки, просмотры, отзывы, авторизация, подписки и другие функции, для которых необходима работа с данными в реальном времени.
Таким образом, Laravel не занимается генерацией каждой страницы сайта, а выполняет роль отдельного API.
WordPress — только административная панель.
Полностью отказываться от WordPress не стал. Он остался привычным инструментом для редакторов, которые продолжают работать с материалами через знакомую административную панель.
По сути, WordPress больше не является движком публичной части сайта. Он отвечает за управление контентом, а отображением страниц занимается Astro.
GitHub Actions — автоматизация сборки и публикации.
За проверку изменений и деплой отвечает GitHub Actions.
Когда редактор вносит изменения через WordPress, автоматически запускается процесс пересборки статического сайта. При этом публикация на продакшене контролируется отдельно: обновления выкатываются вручную и только из ветки main.
Это позволяет автоматизировать рутинные процессы, но сохранить контроль над тем, что именно попадает на рабочий сайт.
Самое интересное: всё это работает на сервере с 1 ядром и 1 ГБ RAM
Главная идея эксперимента — проверить, сколько можно получить от существующего оборудования за счёт правильной архитектуры и оптимизации.
Сейчас вся эта система работает на весьма скромной конфигурации:
- 1 процессорное ядро;
- 1 ГБ оперативной памяти.
Для современного веб-проекта это далеко не впечатляющие характеристики. Поэтому задача заключается не в том, чтобы просто заставить всё работать, а в том, чтобы максимально эффективно использовать доступные ресурсы.
Что уже удалось оптимизировать
За время настройки удалось получить несколько заметных результатов.
1. Статические страницы открываются примерно за 0,5 секунды даже под нагрузкой.
Поскольку основная часть сайта заранее собрана в HTML, серверу не приходится выполнять тяжёлую работу при каждом посещении страницы.
Это одно из главных преимуществ выбранной архитектуры.
2. Вход в WordPress ускорился с 5-9 секунд примерно до 1 секунды.
Административная панель по-прежнему работает на PHP, поэтому её производительность зависит от правильной настройки PHP-FPM и пулов PHP.
После настройки пулов удалось существенно сократить время отклика административной части.
3. MyISAM заменён на InnoDB.
Таблицы базы данных были переведены с MyISAM на InnoDB.
Это позволило избавиться от прежней проблемы с блокировкой таблиц целиком при выполнении операций записи. InnoDB обеспечивает более гибкую работу с блокировками и транзакциями, что особенно важно для сайта с несколькими параллельными процессами.
4. Устранены лишние запросы SEO-данных при пересборке.
Ещё одна оптимизация касается взаимодействия Astro и WordPress.
Раньше после каждой правки сборка повторно запрашивала SEO-данные всех страниц. Для сайта на 2500 страниц это лишняя работа.
Теперь этот процесс оптимизирован, поэтому небольшие изменения не приводят к повторному получению всех SEO-данных.
Где находится предел такой архитектуры?
Самое интересное ещё впереди.
Сейчас система работает, показатели выглядят обнадёживающе, но остаётся главный вопрос: где находится реальный предел производительности сервера с одним ядром и одним гигабайтом оперативной памяти?
Ведь статическая часть — только одна сторона проекта. Есть ещё PHP-FPM, Laravel, база данных, фоновые процессы, автоматические сборки и другие задачи, которые конкурируют за ограниченные ресурсы.
Особенно интересно посмотреть, как сервер будет вести себя при следующих сценариях:
- увеличении количества одновременных посетителей;
- активном использовании API;
- массовых обращениях к функциям лайков и просмотров;
- работе редакторов в WordPress;
- одновременном запуске фоновых задач и пересборки сайта.
Именно здесь станет понятно, насколько эффективно удалось разделить нагрузку между компонентами.
Продолжение эксперимента
Я не ставлю перед собой задачу доказать, что мощные серверы больше не нужны. Идея немного другая: прежде чем платить за дополнительные ресурсы, хочется понять, насколько хорошо можно использовать уже имеющиеся.
Буду продолжать наблюдать за работой системы, тестировать разные варианты оптимизации, искать узкие места и фиксировать реальные результаты.
Своими наблюдениями, техническими решениями, результатами тестов и дальнейшими выводами буду постепенно дополнять эту тему на сайте.
Если вам интересны практическая оптимизация серверов, производительность WordPress, Astro, Laravel и современные подходы к построению веб-проектов — следите за обновлениями.
А сам эксперимент продолжается.
Комментарии
Комментариев пока нет.