TweenTribune — образовательный ресурс от Смитсоновского института (Smithsonian Institution) для детей и подростков от 8 до 18 лет. На сайте публикуются актуальные новости науки, истории и культуры, адаптированные под разный уровень сложности текста (Lexile). Профессиональные журналисты готовят материалы на основе событий, интересных молодой аудитории, а учителя могут использовать их для проведения уроков и дискуссий.
История перехода с WordPress на Drupal
TweenTribune работал в США через школьных учителей. Зарегистрированные ученики заходили на сайт и комментировали события дня, а учителя модерировали комментарии, перед публикацией. В 2008 году основатель TweenTribune Alan Jacobson решил перенести сайт с WordPress на более функциональную и гибкую систему управления контентом Drupal. Он обратился к команде Ebizon для разработки сайта, на котором дети могли бы читать и комментировать разнообразный интересный контент. Учителя могли бы использовать TweenTribune как инструмент обучения. Самое главное, сайт использует уникальный и интересный материал для привлечения учеников. Учителя могут регистрировать свои классы на сайте, после регистрации предоставляется доступ к дополнительным возможностям таким как создание отчетов по комментариям студентов или историям, которые комментировал класс. Это позволяет учителям оценивать и комментировать студентов. Так же на сайте есть Faculty Lounge где учителя могут общаться с учениками, публиковать идеи и планы уроков.
TweenTribune был запущен в марте 2009 года. Сайт был разработан на Drupal 6 с использованием нескольких популярных модулей таких как Views, CCK, ImageCache. Весь код, написанный для реализации дополнительных возможностей TweenTribune, был оформлен в виде модулей Drupal.
Масштабирование
На TweenTribune было пару уникальных задач. Во время учебного процесса в США большое количество авторизованных пользователей создавали максимальное количество подключений к базе данных. Веб-сервер и сервер баз данных были разделены на 2 физических сервера в единой локальной сети. Далее были предприняты следующие меры для увеличения производительности Drupal:
- Оптимизация запросов к базе данных и модулей Drupal.
- Использование Memcache для кэша базы данных.
- Сессии, которые обычно хранятся в базе данных Drupal, так же были перенесены в memcache.
- Использован модуль Boost для кэширования контента для анонимных пользователей.
- Использование Lighttpd для раздачи статического контента такого как css, js, изображения.
- Был использован APC как PHP акселератор.
- Использование Linuх shell, Munin и Nagios для мониторинга.
Memcache
Memcache, SQUID, APC использовались для масштабирования Drupal. Memcache, APC и SQUID были установлены и сконфигурированы на одном сервере, причем конфигурация Memcache изменяется при увеличении траффика и при изменении количества свободной оперативной памяти.
Lighttpd
Lighttpd — это веб-сервер, используемый для раздачи статических файлов (изображения, javascript, css) для уменьшения нагрузки на Apache, так как Lighttpd быстрее чем Apache при раздаче статического контента.
Apache Solr vs DSS (Drupal Search Sucks)
Встроенный в Drupal поиск не подходит, так как он плохо справляется с большими объемами контента, не масштабируется и тормозит. Поиск, интегрированный в Drupal, работает и ищет в той же базе данных, замедляя работу системы. Apache Solr позволяет индексировать ноды, а не страницы. Это означает что он может иметь доступ к аттрибутам нода, которые нелегко разпарсить из сгенерированной страницы. Эти аттрибуты могут быть использованы для фильтрации результатов. Apache Solr более быстр, чем встроенный в Drupal поиск.
InnoDB вместо MyISAM
Преимущества InnoDB:
- InnoDB реализует блокировки на уровне строк для операций вставки (insert) и обновления (update), в то время как MyISAM эти блокировки реализует на уровне таблиц.
- InnoDB обеспечивает целостность данных при помощи транзакций и relationship constraints.
- InnoDB быстрее при работе с таблицами, в которые часто делается запись (операции вставки и обновления), так как блокировки реализованы на уровне записей и изменяется только запись, которая была вставлена или обновлена.
Большой буффер позволяет InnoDB функционировать как база данных в оперативной памяти, первый раз чтение данных происходит с жесткого диска и для последующих операций чтения данные берутся из оперативной памяти. Буффер кэширует даже данные, измененные во время операций вставки и обновления, что позволяет группировать операции записи на жесткий диск для увеличений производительности.
Аппаратное обеспечение
Аппаратное обеспечение состоит из 2-х серверов в единой гигабитной локальной сети:
- Веб-сервер Apache и Memcache:
- Процессор: Quad Socket Quad Core Intel Xeon E7440 2.4GHz
- RAM: 64GB
- Операционная система: Red Hat Enterprise Linux 5 - 64 bit
- Сервер баз данных:
- HDD: RAID 5
- RAM: 12 GB
- Процессор: Single Socket Quad Core Intel Xeon L5520 2.26GHz
При использовании InnoDB важно понимать его отличия от MyISAM и подходить к выбору движка осознанно. InnoDB действительно показывает лучшую производительность на операциях записи, однако при чтении данных он уступает MyISAM. Поэтому выбор движка имеет смысл делать на уровне конкретных таблиц. Например, для таблицы accesslog, куда постоянно записываются данные о посещениях, InnoDB выглядит логичным выбором. В то же время для таблицы node, где на одну операцию записи приходится сотни и тысячи операций чтения, MyISAM может оказаться более эффективным.
Единственный способ приблизить InnoDB к MyISAM по скорости чтения — это выделить значительный объём оперативной памяти, чтобы данные читались напрямую из RAM. Как верно отмечено в статье, в этом случае производительность чтения существенно возрастает. Однако для шаред-хостинга такой подход, как правило, неприменим. В условиях ограниченной оперативной памяти чтение из InnoDB может быть заметно медленнее, чем из MyISAM.
Практический опыт на шаред-хостинге показал, что перевод таблиц с InnoDB на MyISAM позволил сократить время генерации страниц в среднем с 4 секунд до 1–2 секунд. Это наглядно демонстрирует, что InnoDB, несмотря на свои преимущества, подходит не для всех сценариев.
Оптимальным решением в условиях ограниченных ресурсов может быть комбинированный подход: использование InnoDB для таблиц с интенсивной записью и MyISAM для таблиц, ориентированных в первую очередь на чтение. Такой вариант позволяет получить баланс между производительностью и возможностями хостинга, хотя тема выбора движка хранения заслуживает отдельного подробного разбора.
При этом стоит учитывать, что MyISAM значительно уступает InnoDB по надёжности из-за отсутствия транзакций и механизмов восстановления после сбоев, что также должно влиять на итоговое решение.
Что касается выбора веб-сервера, использование Lighttpd в качестве основного решения не рассматривается в первую очередь из-за специализации на связке Nginx, Apache и PHP-FPM. Эти инструменты позволяют глубоко оптимизировать производительность сайтов на Drupal и имеют широкий набор проверенных практик. Опыт работы с Lighttpd ограничен, и на данный момент есть больше потенциала для развития и оптимизации именно в экосистеме Nginx и Apache. Кроме того, с практической точки зрения Nginx в большинстве случаев выглядит более удачным и универсальным решением.
В настоящее время портал является частью Смитсоновского института и функционирует на его официальном домене. Как самостоятельный проект TweenTribune прекратил существование, однако у читателей сохраняется возможность ознакомиться с английским оригиналом статьи, где представлена фотография одной из страниц его прежнего дизайна.
Добавить комментарий