По мотивам За что я люблю Drupal.
Опубликовано по просьбе JiLiZART (перевод, как я понял, тоже его).
Оригинал: erickennedy.org.
Статья датирована годом ранее, так что временные рамки в переводе сохранены
Скоро будет выпущен Drupal 7, так что многие организации должны решить, следует ли им обновляться с Drupal 5 или 6. Drupal хорош, если вы делаете много сайтов и нужно создавать новые сайты быстро и без особой траты на написание кода, или если вам просто нужен блог-на-стероидах.
Работа с Drupal это как жить в double-wide (карточный домик), если вы не можете позволить себе традиционный дом. Если у вас есть сайт, который делался на Drupal и вырос достаточно, чтобы использовать полный рабочий день разработчиков, то вам нужно перенести свой сайт на Yii PHP фреймворк.(PHP ненавистники могут последовать за Onion и использовать Django Python фреймворк, хотя это займет больше времени, смена языка и фреймворка)
Я технический директор сайта, который перешел с Drupal на Yii 30 Апреля 2010 года. На то время, когда мы еще только обсуждали перенос, было трудно найти подходящую информацию, не было даже книг про Yii. Было несколько упоминаний по поводу перехода с Drupal на Yii, но они не содержали достаточно данных, чтобы я был спокоен. Я беспокоился, что Yii может быть медленнее, чем наша сильно оптимизированная инсталляция Drupal, поэтому я решил переписать 20% ядра нашего сайта (что давало нам 80% всего функционала) за 30 дней. Казалось бы, отличный способ проверить продуктивность и производительность фреймворка, и если Yii не даст результата после месяца работы, мы всегда можем вернуться обратно к Drupal и перенести обратно любые новые данные.
Yii был намного быстрее, чем наш Drupal сайт с 150 000 нодами (каждая с переписаным URL) и 50 000 посетителями в день. Да, мы работали как сумасшедшие эти 30 дней (и последующие 15), но оно стоило того. Время, которое мы раньше тратили на отлов и исправление медленных запросов в Drupal, мы с удовольствием тратили разрабатывая на Yii. Реальная выгода от Yii пришла позже, когда мы переработали свой сайт.
С Yii MVC мы изменили всего 2 layout файла против нескольких десятков в Drupal.
Мне жаль, что мы не перешли годом ранее. Вот что мы узнали:
Наша статистика серверов говорит сама за себя. На такое же количество одновременных запросов посетителей (процессов Apache), использование БД и CPU пошло вниз. Использование памяти осталось примерно тем же. За последний год наш траффик увеличился на 60% до 1,5 млн. посещений за месяц в то время как нагрузка на MySQL упала на 66%
Опубликовано по просьбе JiLiZART (перевод, как я понял, тоже его).
Оригинал: erickennedy.org.
Статья датирована годом ранее, так что временные рамки в переводе сохранены
Скоро будет выпущен Drupal 7, так что многие организации должны решить, следует ли им обновляться с Drupal 5 или 6. Drupal хорош, если вы делаете много сайтов и нужно создавать новые сайты быстро и без особой траты на написание кода, или если вам просто нужен блог-на-стероидах.
Работа с Drupal это как жить в double-wide (карточный домик), если вы не можете позволить себе традиционный дом. Если у вас есть сайт, который делался на Drupal и вырос достаточно, чтобы использовать полный рабочий день разработчиков, то вам нужно перенести свой сайт на Yii PHP фреймворк.(PHP ненавистники могут последовать за Onion и использовать Django Python фреймворк, хотя это займет больше времени, смена языка и фреймворка)
Я технический директор сайта, который перешел с Drupal на Yii 30 Апреля 2010 года. На то время, когда мы еще только обсуждали перенос, было трудно найти подходящую информацию, не было даже книг про Yii. Было несколько упоминаний по поводу перехода с Drupal на Yii, но они не содержали достаточно данных, чтобы я был спокоен. Я беспокоился, что Yii может быть медленнее, чем наша сильно оптимизированная инсталляция Drupal, поэтому я решил переписать 20% ядра нашего сайта (что давало нам 80% всего функционала) за 30 дней. Казалось бы, отличный способ проверить продуктивность и производительность фреймворка, и если Yii не даст результата после месяца работы, мы всегда можем вернуться обратно к Drupal и перенести обратно любые новые данные.
Yii был намного быстрее, чем наш Drupal сайт с 150 000 нодами (каждая с переписаным URL) и 50 000 посетителями в день. Да, мы работали как сумасшедшие эти 30 дней (и последующие 15), но оно стоило того. Время, которое мы раньше тратили на отлов и исправление медленных запросов в Drupal, мы с удовольствием тратили разрабатывая на Yii. Реальная выгода от Yii пришла позже, когда мы переработали свой сайт.
С Yii MVC мы изменили всего 2 layout файла против нескольких десятков в Drupal.
Мне жаль, что мы не перешли годом ранее. Вот что мы узнали:
- Drupal не лучший способ чтобы начинать с нуля. Основной продажный пункт Drupal это “Зачем делать свою CMS?”. Как и многие веб разработчики, я писал все веб приложения с нуля (в 1999 и 2000) и ценю возможность сосредоточиться на уникальных бизнес потребностях приложения, а не писать свой собственный код для обработки аутентификации, валидации, SQL иньекций и др.
У компании, которую я помог основать в начале 2007 года, был прототип сайта на Drupal, и я был готов увидеть, что может сделать Drupal, прежде чем бросить его ради Ruby On Rails. Повальное увлечение Ruby напомнило мне увлечение Java в 1997 году. Я был стажером компании WebEx competitor в 1997-99, которая убила свою производительность, начав писать свой сервер на Java до серверного оборудования и VM оптимизаций позволяющих масштабироваться. PHP показал себя при переделке Friendster и на Facebook, и наши пользователи не хотят увидеть fail whale, если мы столкнемся с проблемами масштабируемости в Ruby.
Конечно, легче начать с Drupal, чем писать каждую строчку в PHP самостоятельно. Но, есть куча PHP 5 фреймворков начатых в 2008 году и прошедших испытания в 2009 году. PHP разработчик, начиная создавать веб-приложение сейчас (и продолжая работать над сайтом в будущем), будет либо выбирать фреймворк либо начинать с нуля используя PHP библиотеки (PECL или PEAR).
- Если Drupal фреймворк, то только Машина Руби Голдберга будет любить его (Машина, выполняющая простые действия сложным способом). Drupal разработан для того чтобы быть расширяемым без особых знаний в PHP программировании. Это хорошо, если вы просто стилизуете сайт с простым контентом или у вас мало посещаемый сайт. Если вы работаете полный рабочий день за написанием модулей для изменения форм и добавления функциональности, вы потратите больше времени подавляя функционал Drupal который вам не нужен, нежели создавая его на фреймворке. Yii имеет противоположный подход — вы можете использовать Ruby on Rails-like ORM, если он достаточно быстрый и оптимизировать только 10% запросов, которые нужно просто переписать на MySQL.
- Community-contributed модули склонны к featuritis («фичемании»?) и ошибкам, которые являются результатом чрезмерной сложности.
Есть очень много contrib модулей для Drupal, и если у вас есть разработчики на полный рабочий день, вы вероятно просто решите, как мы это делали, ассимилировать часть дополнительных модулей в ваши собственные. Модули изменения и кеширования изображений в Drupal яркий тому пример. Поскольку модули предназначены для решения общих задач (так что они могут работать с произвольным количеством других модулей!), они включают тонны функционала который вы никогда не будете использовать. В нашем случае, нам нужно сделать превьюшки нескольких размеров, которые мы получим используя ImageMagick. Чтобы сделать это, нам пришлось включить 4 модуля, каждый с кучей PHP файлов: ImageAPI, ImageAPI для ImageMagick, ImageCache, и ImageCache UI, вместо фактических комманд для создания эскизов в 2х таблицах базы данных. Если при обновлении части цепочки модулей что то сломается, это займет намного больше времени на поиск причин, вместо того чтобы делать только то что вам нужно.
Yii также имеет расширение для работы с изображениями (адаптированное из Kohana), но оно включает в себя не нужную нам функциональность ( rotate! flip! ) и осложнено тем, что разработано для прозрачного переключения между ImageMagick и GD (у GD проблемы с файлами больше 2МБ). Несмотря на все это, она все еще не позволяет изменять размер изображения на лету используя RewriteRule если превьюшка не существует.
Так что я просто создал index.php фаил, который обрабатывает RewriteRule запросы на выделенном для изображений сервере и посылает экранированную shell команду для конвертирования напрямую бинарнику. Это значит, что эти RewriteRule запросы не затрагивают index.php файл Yii, снижая накладные расходы и время, необходимое для изменения размера изображений и сброса кеша. Это всего лишь одна страница на php принимающая аргументы которые передаются в один вызов бинарнику, и это намного проще при поддержке и тестировании если обновится ImageMagick.
- Drupal содержит багаж PHP 4 совместимости. Однажды, когда я решил взглянуть на PHP фреймворки, я быстро понял, что хочу только 100% PHP5 ООП фреймворк. Вы не встретите много людей, которые утверждают, что процедурная система хуков превосходит ООП подход. Хотя Drupal 7 требует PHP5, как и CodeIgniter 1.0 и другие старые фреймворки на PHP, они все еще несут багаж совместимости. Кто хочет такой багаж?
- Не хотите чтобы Drupal 6 или 7 замедлили ваш Drupal 5 сайт? Не хотите иметь дело с устаревшим jQuery? Для большинства сайтов это нормально. Мы действительно заботимся о скорости, поскольку Google и Microsoft, показали, что пользователи более лояльны к быстрым сайтам. В 2009 году, когда Drupal 6 стал стабильным, мы застряли на Drupal 5 из-за измеримых преимуществ в скорости. Проблема в том, что Drupal 5 включает в себя jQuery 1.0. Вы можете установить contrib модуль, который патчит jQuery до 1.2 (и обновляет Drupal функции, которые ссылаются на него), но эта версия тоже старая. Забудьте о jQuery 1.3x и Drupal 5.
- API полей/(CCK) в Drupal сведет вас с ума, и это часть ядра Drupal 7. Зачем использовать $node->ip, когда вы можете использовать $node->field_ip[0][‘value’]. И если вы захотите чтобы два разных типа контента имели поле с одним и тем же именем, CCK поместит их в свою собственную таблицу ( content_field_ip ) с восхитительными именами столбцов ( field_ip_value). Конечно, Drupal может понять этот беспорядок, когда загружается нода, но на это не красиво смотреть. MySQL запросам нужно много LEFT JOIN’ов чтобы обработать все дополнительные CCK таблицы, и те излишние сложные запросы, которые в конечном итоге слишком часто попадают в логи медленных запросов. Мне, наконец, надоело пытаться оптимизировать все эти медленные запросы и я решил избавиться от CCK, что привело меня к PHP фреймворкам, а затем и к Yii.
Миграция наших данных в Yii заняла столько же времени, как если бы мы избавлялись от CCK модуля оставаясь на Drupal. Тем не менее мы смогли начать с чистой БД без всех тех дополнительных таблиц которые Drupal использует для своих внутренних нужд. В нашей старой БД было 173 таблицы, в новой 54.
- Drupal намного медленнее чем Yii.
Drupal расширяем если вы будете кэшировать ВСЕ с memcached и APC на борту и перепишите все медленные запросы. Кеширование особенно важно, если вы используете SEO адреса для всех ссылок, поскольку каждый вызов l() порождает еще один запрос к базе данных. Так, среднестатистическая страница имеет 50+ запросов, по сравнению 3-5 в Yii. После перехода, наше среднее время загрузки снизилось с 163мс до 63мс в соответствии с Google Webmaster Tools. Еще лучше, Yii + APC настолько быстрые, что нам нет необходимости использовать memchached, упрощение кода и операций.
Наша статистика серверов говорит сама за себя. На такое же количество одновременных запросов посетителей (процессов Apache), использование БД и CPU пошло вниз. Использование памяти осталось примерно тем же. За последний год наш траффик увеличился на 60% до 1,5 млн. посещений за месяц в то время как нагрузка на MySQL упала на 66%
