TweenTribune — новостной сайт для детей и подростков от 8 до 18 лет, ежедневно публикующий уникальные и интересные для детей новости. События отбираются детьми совместно с профессиональными журналистами. Дети могут публиковать ссылки на события, которыми хотели бы поделиться, публиковать свои собственные события, и комментировать новости.
Более 53 тысяч учителей в США используют этот сайт в своих классах.
Более 5 миллионов просмотров страниц в месяц.
10 000 нодов добавляется ежедневно.
История перехода с WordPress на Drupal
TweenTribune работал в США через школьных учителей. Зарегистрированные ученики заходили на сайт и комментировали события дня, а учителя модерировали комментарии, перед публикацией.
В 2008 году основатель TweenTribune Alan Jacobson решил перенести сайт с WordPress на более функциональную и гибкую систему управления контентом Drupal. Он обратился к команде Ebizon для разработки сайта, на котором дети могли бы читать и комментировать разнообразный интересный контент. Учителя могли бы использовать TweenTribune как инструмент обучения. Самое главное, сайт использует уникальный и интересный материал для привлечения учеников.
Учителя могут регистрировать свои классы на сайте, после регистрации предоставляется доступ к дополнительным возможностям таким как создание отчетов по комментариям студентов или историям, которые комментировал класс. Это позволяет учителям оценивать и комментировать студентов. Так же на сайте есть Faculty Lounge где учителя могут общаться с учениками, публиковать идеи и планы уроков.
TweenTribune.com был запущен в марте 2009 года. Сайт был разработан на Drupal 6 с использованием нескольких популярных модулей таких как Views, CCK, ImageCache.
Весь код, написанный для реализации дополнительных возможностей TweenTribune, был оформлен в виде модулей Drupal.
Масштабирование
На TweenTribune.com было пару уникальных задач. Во время учебного процесса в США большое количество авторизованных пользователей создавали максимальное количество подключений к базе данных. Веб-сервер и сервер баз данных были разделены на 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 наоборот, на одну запись в таблицу node может приходиться сотни и тысячи чтений.
Единственный способ для InnoDB догнать MyISAM по скорости чтения данных - это много выделенной оперативки, как верно указано в статье, в этом случае чтение будет происходить из памяти. Но это не вариант для шаред хостингов. И чтение из InnoDB будет сильно медленней чем из MyISAM.
Реальный результат, который я получил на шаред хостинге при смене таблиц с InnoDB на MyISAM - ускорение времени создания страниц в среднем с 4 секунд до 1-2 секунд.
Вывод такой, InnoDB действительно круче, но не для всех он подходит.
спасибо, за отличное пояснение. Абсолютно согласен с Вами к выбору движка нужно с умом подходить и в условиях ограниченности оперативы применение комбинированного решения (часть таблиц на MyISAM, а часть на InnoDB) идеальный вариант.
Эта тема достойна отдельной статьи.
С другой стороны MyISAM значительно менее надежен чем InnoDB за счет отсутствия механизма транзакций.
А можете объяснить почему нельзя использовать lighttpd как основной веб-сервер, без apache и nginx, почему вы этим не занимаетесь?
Просто потому что я специализируюсь на nginx, apache, php-fpm - и добиваюсь хорошей скорости работы Drupal сайтов.
У меня опыта работы с Lighttpd нет. Не занимаюсь потому что есть куда расти с nginx, apache и php-fpm.
Возможно в будущем обратим на него внимание, но на мой взгляд Nginx все таки удачнее чем Lighttpd.
http://www.wikivs.com/wiki/Lighttpd_vs_nginx