Слово wiki почти неизбежно ассоциируется с Википедией, и отсюда возникает первая ошибка при выборе хостинга для MediaWiki. Кажется, что движку энциклопедии нужен если не собственный серверный зал, то хотя бы мощный VPS. Для небольшой базы знаний это совершенно необязательно.
MediaWiki может использоваться внутри компании для инструкций и документации, в небольшом тематическом сообществе или в крупном публичном проекте с тысячами страниц. Во всех случаях работает одна CMS, но нагрузка получается совершенно разной.
У MediaWiki есть и особенность, которая отличает ее от обычного сайта. Здесь важно не только количество страниц и посетителей. Страницы редактируются, сохраняются их предыдущие версии, работают поиск и расширения, пользователи загружают файлы, а часть операций выполняется через очередь заданий. Поэтому хороший хостинг для MediaWiki выбирают исходя из того, как именно будет использоваться wiki.
Небольшой wiki не нужен огромный сервер
Представим внутреннюю базу знаний небольшой компании. Сотрудники хранят в ней инструкции, правила работы, документацию по проектам и ответы на типовые вопросы. В течение дня несколько человек редактируют материалы, остальные открывают готовые страницы.
Для такого сценария MediaWiki вполне может работать на хорошем виртуальном хостинге.
Движку нужны веб-сервер, PHP и поддерживаемая система управления базами данных. Конкретные версии программного обеспечения меняются вместе с выпусками MediaWiki, поэтому перед установкой необходимо смотреть требования именно вашей версии CMS.
Это важнее рекламной отметки MediaWiki в списке поддерживаемых приложений. Автоматическая установка из панели удобна, но она не делает хостинг технически лучше.
Проверьте PHP и необходимые расширения
MediaWiki написана на PHP и использует ряд PHP-расширений. Некоторые дополнительные возможности могут предъявлять собственные требования.
На виртуальном хостинге пользователь не управляет системным окружением полностью, поэтому до оплаты стоит убедиться, что нужная версия PHP и необходимые расширения доступны. Хорошо, если версию PHP можно переключать самостоятельно через панель.
Особенно внимательно это стоит проверить перед переносом старой wiki на новый сервер. Устаревшая версия MediaWiki и современное серверное окружение могут оказаться несовместимы. В таком случае правильнее сначала спланировать обновление самой CMS, а не пытаться бесконечно подстраивать новый хостинг под давно устаревшее приложение.
Для обслуживания MediaWiki также может понадобиться командная строка. Через нее запускаются служебные сценарии, поэтому для проекта, который администрируется разработчиком или системным администратором, наличие SSH будет серьезным плюсом.
База данных здесь важнее, чем кажется
Статья в wiki выглядит как обычная веб-страница, но за ней стоит база данных. MediaWiki хранит там содержимое и значительную часть информации, необходимой для работы системы.
Причем wiki живет иначе, чем статичный корпоративный сайт. Материал могут исправлять десятки раз. Старая версия при этом не просто исчезает после нажатия кнопки сохранить. История изменений является одной из основных возможностей wiki.
Поэтому размер проекта нельзя оценивать только по количеству текущих страниц.
Две wiki по пять тысяч статей способны занимать разный объем и создавать разную нагрузку. В одной материалы почти не меняются, а в другой над ними постоянно работает сообщество редакторов.
На небольшом проекте об этом можно особо не беспокоиться. Но если wiki активно развивается годами, база данных постепенно становится одной из важнейших частей инфраструктуры.
MediaWiki растет не так, как обычный сайт
У интернет-магазина рост хорошо заметен по товарам и заказам. У фотосайта быстро увеличивается медиатека. Wiki способна внешне почти не измениться, хотя внутри уже накопилось огромное количество данных.
Сегодня на странице написана одна инструкция. Завтра сотрудник исправил несколько пунктов. Через неделю другой человек добавил новый раздел. Потом информацию актуализировали еще несколько раз.
Читатель по-прежнему видит одну страницу. MediaWiki при этом должна обеспечивать работу истории изменений и связанных с ней механизмов.
Именно поэтому для большого проекта важны не красивые цифры в рекламном тарифе, а нормальная работа PHP, базы данных, дисковой подсистемы и кеширования.
Посетители и редакторы создают разную нагрузку
Для публичной wiki особенно полезно разделять две аудитории.
Первая приходит читать уже опубликованные материалы. Вторая входит в систему, редактирует страницы, просматривает историю, загружает файлы и выполняет другие действия.
Готовую страницу для анонимного читателя во многих случаях можно эффективно кешировать. С персонализированными действиями зарегистрированного пользователя все сложнее.
Поэтому тысяча обычных просмотров и тысяча активных действий редакторов не являются одинаковой нагрузкой на сервер.
Это одна из причин, почему бессмысленно выбирать тариф по формуле определенное число посетителей равно определенному количеству оперативной памяти.
У MediaWiki есть очередь заданий
Некоторые операции невыгодно полностью выполнять в момент, когда пользователь сохраняет страницу. Иначе ему пришлось бы ждать завершения всей цепочки связанных действий.
Для этого MediaWiki использует очередь заданий.
На небольшой wiki она может долго оставаться незаметной владельцу. По мере роста проекта фоновых операций становится больше, и способ обработки очереди приобретает значение.
Если wiki крупная или активно редактируется, запуск фоновых задач нужно продумать отдельно. На собственном сервере администратор получает больше возможностей для настройки подобных процессов. На виртуальном хостинге необходимо смотреть, какие средства запуска задач предоставляет провайдер.
Поэтому Cron и возможность работы со служебными сценариями для MediaWiki полезнее, чем очередные десятки гигабайт диска, которые проект пока не использует.
Расширения способны полностью изменить требования
Чистая MediaWiki и MediaWiki с большим набором расширений могут ощущаться как разные проекты.
Расширения добавляют редакторы, формы, работу с данными, дополнительные способы поиска, авторизацию и множество других функций. Вместе с возможностями иногда растет и нагрузка.
Нельзя заранее утверждать, что любое расширение требует более мощного сервера. Одни почти незаметны для инфраструктуры, другие серьезно меняют характер работы системы.
Перед установкой крупного расширения полезно посмотреть его собственные требования и рекомендации. Особенно если оно использует внешние программы или сервисы, которые могут быть недоступны на обычном виртуальном хостинге.
Кеш для MediaWiki действительно имеет значение
Вот где MediaWiki заметно отличается от многих небольших CMS. Ее архитектура предусматривает несколько уровней кеширования, и по мере роста wiki они становятся все важнее.
Начать стоит с OPcache. Он позволяет PHP повторно использовать уже скомпилированный код вместо выполнения одной и той же подготовительной работы при каждом запросе. В официальной документации MediaWiki его использование прямо рекомендуется для повышения производительности.
Для локального кеша MediaWiki может использовать APCu. Для основного кеша более серьезных установок применяются Memcached или Redis.
Это, однако, не означает, что при создании wiki на двадцать сотрудников нужно немедленно арендовать VPS, устанавливать Redis и строить сложную серверную архитектуру.
Для маленьких установок сама документация MediaWiki предостерегает от излишнего усложнения. Начинать разумнее с нормального PHP-окружения и базовых механизмов кеширования, а инфраструктуру расширять по необходимости.
Публичная wiki хорошо выигрывает от кеширования страниц
У открытой энциклопедии может быть очень много читателей и относительно небольшое количество людей, которые непосредственно редактируют материалы.
Это удобный сценарий для кеширования.
Если готовую страницу запрашивают снова и снова, нет необходимости каждый раз полностью формировать ее с нуля. Для крупных проектов могут использоваться кеширующие прокси и другие механизмы, позволяющие отдавать уже подготовленный результат.
Так сервер MediaWiki занимается динамической работой тогда, когда это действительно необходимо.
Но у внутренней корпоративной wiki картина может быть другой. Там почти каждый посетитель авторизован, а страницы регулярно меняются. Поэтому нельзя просто посмотреть на посещаемость Википедии, уменьшить ее в тысячу раз и получить требования к своему серверу.
VPS нужен не из-за самого MediaWiki
Переход на VPS становится логичным, когда ограничения виртуального хостинга начинают мешать конкретному проекту.
Например, требуется управлять серверным кешем, устанавливать дополнительные компоненты, глубже настраивать PHP и базу данных или более гибко обрабатывать очередь заданий.
Другой вариант — wiki уже создает устойчивую нагрузку, которую неудобно обслуживать в общей среде.
Тогда собственный виртуальный сервер дает больше свободы. Администратор может распределять ресурсы между веб-сервером и базой, использовать Memcached или Redis, менять серверную конфигурацию и анализировать производительность значительно глубже.
Но VPS приносит и новую обязанность: его необходимо обслуживать. Обновления системы, безопасность, конфигурация служб, резервные копии и наблюдение за сервером теперь становятся чьей-то ответственностью.
Если в организации нет человека, который этим занимается, управляемый VPS может оказаться разумнее самостоятельного.
Не забудьте про файлы, поиск и резервные копии
Текстовые статьи сами по себе занимают относительно немного места. Но wiki редко остается исключительно текстовой.
В нее начинают загружать схемы, скриншоты, фотографии, PDF, инструкции и другие материалы. В корпоративной базе знаний вложений иногда оказывается больше, чем ожидалось при запуске.
Поэтому дисковое пространство все же имеет значение, просто оценивать его нужно вместе с характером проекта.
Загрузка файлов может потребовать больше возможностей сервера
MediaWiki умеет работать с загружаемыми файлами и создавать уменьшенные версии изображений. Некоторые форматы и дополнительные функции могут зависеть от доступных серверных инструментов.
На дешевом виртуальном хостинге часть функций запуска внешних процессов может быть ограничена из соображений безопасности. Официальная документация MediaWiki отдельно обращает внимание на то, что это способно повлиять, например, на обработку изображений.
Если wiki должна активно работать с медиафайлами, лучше заранее проверить требуемые возможности, а не обнаруживать ограничение после переноса всей базы знаний.
Поиск маленькой и огромной wiki тоже отличается
Пока в базе несколько сотен страниц, поиск редко воспринимается как инфраструктурная задача. С ростом объема контента и требований пользователей ситуация меняется.
Крупным проектам могут понадобиться более развитые поисковые решения и соответствующие расширения. А это уже дополнительные службы, память и администрирование.
Поэтому снова работает тот же принцип: не нужно заранее строить инфраструктуру Википедии для небольшой базы инструкций. Но полезно выбирать площадку так, чтобы рост не закончился вынужденным переездом при первом серьезном расширении функциональности.
Копировать нужно не только папку с сайтом
У wiki ценность представляет прежде всего накопленная информация. Потерять несколько лет истории корпоративной документации или работу сообщества намного неприятнее, чем заново установить сам движок.
Резервное копирование должно учитывать базу данных и загруженные пользователями файлы.
Перед обновлением MediaWiki или крупных расширений также разумно иметь актуальную копию, из которой проект можно восстановить.
При выборе хостинга выясните, как часто создаются автоматические резервные копии, что именно в них входит, сколько времени они хранятся и как выполняется восстановление.
Для действительно ценной базы знаний желательно иметь независимую копию вне основного хостинга. Если учетная запись провайдера окажется недоступна, резервная копия внутри той же панели мало поможет.
Выбирайте сервер по тому, какой будет ваша wiki
Вместо поиска универсального тарифа для MediaWiki полезнее сначала определить тип проекта.
Небольшая внутренняя база знаний. Несколько десятков сотрудников, умеренное количество страниц и вложений, без тяжелых расширений. Здесь обычно достаточно качественного виртуального хостинга с совместимым PHP, базой данных, OPcache, резервными копиями и возможностью запускать необходимые служебные задачи.
Тематическая wiki сообщества. Материалы читают анонимные посетители, зарегистрированные участники постоянно что-то исправляют и дополняют. Здесь уже стоит внимательнее следить за нагрузкой, базой данных, кешированием, очередью заданий и ростом загружаемых файлов.
Крупная публичная энциклопедия. Много читателей, редакторов, страниц и расширений. Для такого проекта VPS или отдельная серверная инфраструктура становятся естественным выбором. По мере роста можно разделять компоненты системы, использовать внешний кеш и несколько серверов.
MediaWiki способна масштабироваться значительно дальше одного VPS. Крупные установки могут использовать несколько веб-серверов, балансировку нагрузки, отдельные серверы баз данных и развитую систему кеширования. Но это верхняя часть лестницы, а не обязательная стартовая точка.
Именно поэтому я бы не искала тариф с максимальными характеристиками на старте. Лучше выбрать провайдера, у которого есть нормальный путь роста от виртуального хостинга к VPS и более мощной инфраструктуре.
Перед оплатой проверьте совместимость вашей версии MediaWiki с PHP и базой данных, доступность необходимых расширений PHP, SSH и Cron, если они нужны для обслуживания, возможности резервного копирования и ограничения ресурсов. Для существующей wiki полезно также оценить размер базы и файлов, текущую нагрузку и используемые расширения.
В результате маленькая корпоративная wiki может годами прекрасно жить на обычном хостинге, а большой публичный проект постепенно превратиться в инфраструктуру из нескольких серверов. Между этими крайностями нет единственной правильной конфигурации.
Хостинг для MediaWiki стоит выбирать не по масштабу Википедии и не по громкому названию специального тарифа. Смотрите на собственную wiki: кто будет ее читать, сколько людей будет редактировать материалы, какие расширения понадобятся и как быстро будет расти накопленная база знаний. Именно эти вопросы гораздо точнее показывают, какой сервер действительно нужен проекту.
