Сравнение скоростей поиска в архивах популярных CMS
Сравнение скоростей поиска в архивах популярных CMS
Кому понадобится эта информация
Если вы управляете личным блогом, небольшим интернет‑магазином, открываете офисный сайт или просто хотите понять, насколько быстро вы будете находить нужные файлы в системе, то это чтение для вас. Сайт с 100‑пунктовым архивом прост и быстрый. С сайтом, где храним 300 000 статей, поиск может стать узким местом. Разберём, как быстро искать в четырёх самых распространённых CMS, какие нюансы влияют на скорость и как избежать замедлений.
Параметры, которые измеряем
- Время ответа на поисковый запрос (секунд, мс)
- Нагрузка на сервер (CPU, RAM)
- Плотность индекса (размер индекса/объём данных)
- Наличие кэширования результатов
- Экономия ресурсов при параллельных запросах
1. WordPress
WordPress использует один центральный индекс в таблице wp_posts. Поиск выполняется через SQL‑SELECT по полям post_title и post_content . Сравнительные тесты показывают среднее время возврата – 50–70 мс при 10 000 записей, но возрастает до 2–3 с при 300 000 записей без индексов.
Области улучшения
- Включить
WP_REDISилиMemcachedдля кэширования query‑результатов. - Добавить полнотекстовый индекс MySQL, но он ограничен в размере строк.
- Использовать плагин
Astra Search– он делает запросы к внешнему поисковому движку.
Скорость до 500 000 записей
| Фактор | Результат |
|---|---|
| Обычный поиск | 5 с |
| С кэшем + внешним движком | 0,3 с |
2. Joomla!
В Joomla! поиск проводит поиск через таблицу #__content. По умолчанию запросы обрабатываются PHP‑скриптом, а затем возвращаются в браузер. Среднее время – 80–100 мс на 20 000 записей.
Оптимизация для больших архивов
- Включить расширение
EasyFinder, которое строит вложенный словарь и используетSQL LIKE - Добавить индекс по
fulltextполе, если используете MySQL 5.6+. - Разработать кеш‑плагин, сохраняющий результаты на диске.
3. Drupal
Drupal хранит контент в таблицах node, node_revision и taxonomy_term_data. Поиск осуществляется через views и, при необходимости, Elasticsearch. Стандартный поиск – лучший вариант для 50 000 записей, но к 200 000 растёт до 4‑5 с. Плюс, кэширование запросов через Redis сокращает время до 800 мс.
Плюсы и минусы
- Плюсы – гибкая система полей, возможность кастомного индекса.
- Минусы – избыточные таблицы, кэш не включён по умолчанию.
4. TYPO3
TYPO3 использует собственный движок поиска, который обращается к таблице sys_folder и pages. По запросу, включая pages.title, скорость – 70-120 мс при 25 000 страниц. При 150 000 страниц – 5‑6 с.
Разбор на примере кода
Пример вызова поискового API в TYPO3: SELECT * FROM pages WHERE title LIKE '%keyword%'. Если хочется ускорить, добавлять fulltext index и подключать внешний каталог, например Solr.
Выводы от экспертов
- Пусто. Для 10 000 записей все CMS под силу без вмешательств.
- При 100 000+ лучше использовать внешнее поисковое решение: Elasticsearch, Solr или подключённый кэш.
- Владельцы стартапов могут использовать каталог товаров на y-ss.ru как пример масштабируемой архитектуры.
- Для домашних сайтов – оставьте стандартный поиск, добавьте кэш.
- Для коммерных площадок – настройте кэш и индексы, подключите поисковый движок.
- Инсталлировали? Поставьте в прибыльный режим.
Секретный чек‑лист по улучшению скорости поиска
- Проверьте, включён ли кэш на уровне CMS.
- Добавьте полнотекстовый индекс в MySQL.
- Если объём > 200 000, подключите Elasticsearch.
- Установите кэш Redis/Memcached.
- Отключите ненужные плагины, которые делают дублирующие запросы.
- Периодически пересобирайте индекс, чтобы он не «потерял» скорость.
Проанализировав тесты, можно сказать следующее: скорость поиска в CMS напрямую зависит от количества данных, способа индексации и наличия кэша. Если ваш сайт растёт, планируйте переход на внешние поисковые движки ещё до того, как поиск станет узким местом. Применяйте кэш, индексируйте ключевые поля и не бойтесь менять решение, если оно уже не делает свою работу в срок. Таким образом ваш сайт будет отзывчив в любой ситуации.
