7 причин перейти с Drupal на Yii

Drupal 7 скоро будет выпущен, поэтому многим организациям необходимо решить, следует ли обновлять Drupal 5 или 6. Drupal - это хорошо, если вы создаете много сайтов и вам нужно быстро создавать новые сайты без большого количества кода или если вам просто нужно сайт с блогом на стероидах.

Работа на Drupal похожа на жизнь в двойная ширина : это лучшее решение, если вы не можете позволить себе индивидуальный дом. Если у вас есть сайт, который был запущен на Drupal и достаточно вырос, чтобы нанимать разработчиков на полный рабочий день, вам следует подумать о переносе своего сайта на Yii PHP Framework , (PHP ненавистники могут следовать за луком и использовать Django Python Framework , хотя это займет больше времени, чтобы изменить рамки и языки программирования.)

Я технический директор сайт который переключился с Drupal на Yii 30 апреля 2010 года. Было трудно найти информацию, когда мы обсуждали переписывание, и не было даже книга о Yii еще. Было несколько комментариев о переходе с Drupal на Yii, но они не включали достаточно данных, чтобы меня успокоить. Я беспокоился о том, что Yii может быть медленнее, чем наша сильно оптимизированная установка Drupal, поэтому я решил переписать основные 20% нашего сайта (которые обеспечили 80% нашей функциональности) за 30 дней. Это казалось отличным способом проверить производительность и производительность платформы Yii, и если Yii не улучшится после этого месяца, мы всегда можем вернуться к Drupal и скопировать любые новые данные.

Yii был намного быстрее, чем Drupal для нашего сайта с 150 000 узлов (каждый с переписанным URL) и 50 000 посетителей в день. Да, мы работали сумасшедшие часы в течение этих 30 дней (и последующих 15), но это того стоило. Время, которое мы раньше тратили на работу с медленными запросами Drupal, было использовано лучше, и было гораздо интереснее разрабатывать на Yii, чем на Drupal. Настоящее преимущество Yii пришло позже, когда мы изменили дизайн нашего сайта. В MVC от Yii нам нужно было всего лишь изменить 2 файла макета против нескольких десятков в Drupal.

Я просто хочу, чтобы мы перешли на год раньше. Вот что мы узнали:

1. Drupal - не лучший способ избежать начала с нуля . Основная цель Drupal для разработчиков - « зачем катать свою собственную CMS? » Как и многие разработчики, я написал целые веб-приложения с нуля (в 1999 а также 2000 ) и высоко оценил возможность сосредоточиться на уникальных бизнес-потребностях приложения вместо того, чтобы писать свой собственный код для обработки всех аспектов аутентификации, проверки формы, предотвращения атак с использованием SQL-инъекций и т. д. У компании, которую я основал в начале 2007 года, был прототип веб-сайт на Drupal, и я хотел посмотреть, что может сделать Drupal, прежде чем выбросить его для Ruby on Rails. Рубиновое увлечение напомнило мне о увлечении Java в 1997 году. Я был стажером в WebEx конкурент в 1997-99 гг. это привело к снижению их производительности путем кодирования сервера на Java до того, как серверное оборудование и виртуальные машины позволили масштабируемость. PHP зарекомендовал себя с переписыванием Friendster и на Facebook, и наши пользователи не хотели видеть проваленный кит если мы столкнулись с проблемами масштабируемости с Ruby.
   Конечно, легче начать работу с Drupal, чем программировать каждую строчку PHP самостоятельно. Но несколько фреймворков PHP 5 были запущены в 2008 году и были протестированы в 2009 , Разработчик PHP, начинающий работу с веб-приложением (и работающий полный рабочий день только на этом сайте), либо выберет платформу, либо начнет с нуля и использует библиотеки PHP (PECL или PEAR)
2. Если Drupal это фреймворк, только Руб Голдберг мог бы любить это . Drupal предназначен для расширения без особого программирования на PHP. Это хорошо, если вы просто разрабатываете простой контентный сайт или у вас мало трафика. Если вы работаете над созданием постоянных модулей для настройки форм и добавления функциональности, вы потратите больше времени на подавление нежелательных функций Drupal, чем на создание фреймворка. Yii использует противоположный подход - вы можете использовать Ruby на Rails-подобные ORM если он достаточно быстрый и оптимизирует только 10% запросов, для которых требуется MySQL с ручным кодированием.
3. Модули, созданные сообществом, склонны к фавриту и ошибкам, возникающим из-за ненужной сложности . Существует слишком много модулей, добавленных в Drupal, и если у вас есть постоянные разработчики, вы, вероятно, просто решите, как и мы, ассимилировать части добавленных модулей в ваши собственные пользовательские модули. Модули Drupal для изменения размера и кэширования изображений являются отличным примером этого. Поскольку модули спроектированы так, чтобы быть универсальными (чтобы они могли работать с произвольным числом других модулей!), Они включают в себя множество функций, которые вы никогда не будете использовать. В нашем случае нам просто нужно было сделать миниатюры разных размеров, что делает двоичный файл преобразования ImageMagick. Чтобы получить это, мы должны были включить 4 модуля, каждый с кучей файлов php: ImageAPI, ImageAPI для ImageMagick, ImageCache и пользовательский интерфейс ImageCache. Тогда фактические команды для создания миниатюр находятся в 2 таблицах в базе данных. Если это перестает работать при обновлении части цепочки, диагностика проблемы займет гораздо больше времени, чем если бы вы создали только то, что вам нужно.
   Yii также имеет расширение для изменения размера изображения (адаптировано из библиотеки изображений Kohana), но оно сложное, поскольку оно позволяет легко переключаться между ImageMagick и GD. (У GD проблемы с 2 MB + изображениями.) Несмотря на все это, он все еще не позволял нам изменять размеры изображений на лету, используя RewriteRule, если миниатюра не существовала. Поэтому я создал простой файл index.php, который просто обрабатывает обратные вызовы RewriteRule на выделенном виртуальном хосте образа и отправляет экранированные команды непосредственно в двоичный файл преобразования. Это означает, что эти обратные вызовы RewriteRule не проходят через файл Yii index.php, что снижает накладные расходы и время, необходимые для операций изменения размера и кэширования изображения. Это всего лишь страница PHP, и аргументы передаются в один вызов двоичному файлу преобразования, поэтому намного проще тестировать и поддерживать, когда мы обновляем ImageMagick.
4. У Drupal есть багаж PHP 4 . Как только я решил рассмотреть фреймворки PHP, я быстро понял, что мне нужен только 100% строгий фреймворк PHP 5 OOP. Вы не видите много людей, утверждающих, что процедурный подход "крючков" в Drupal превосходит ООП. В то время как Drupal 7 требует PHP 5, как CodeIgniter и другие старые PHP-фреймворки, он по-прежнему несет в себе багаж обратной совместимости. Кто хочет чужой багаж?
5. Не хочу Drupal 6 или 7, чтобы замедлить Drupal 5 сайт? Разобраться с устаревшим jQuery . Для большинства сайтов это нормально. Мы действительно заботимся о скорости, потому что Google и Microsoft продемонстрировали, что пользователи более лояльны к быстрым сайтам. В 2009 году, когда появился Drupal 6, мы остановились на Drupal 5 из-за ощутимого преимущества в скорости. Проблема в том, что Drupal 5 включает в себя jQuery 1.0. Вы можете добавить готовый модуль для исправления jQuery до 1.2 (и обновить функции Drupal, которые ссылаются на него), но это все еще старая версия. Забудьте про jQuery 1.3x и Drupal 5.
6. Полевой комплект разработки API / контента (CCK) для Drupal сведет вас с ума, и он является частью ядра Drupal 7 . Зачем использовать $ node-> ip, если вы можете использовать $ node-> field_ip [0] ['value']. И если вы решите, что два типа контента должны оба иметь текстовое поле с одинаковым именем, CCK поместит его в собственную таблицу (content_field_ip) с восхитительными именами столбцов (field_ip_value). Конечно, Drupal может распутать этот беспорядок, когда загружен полный узел, но это не очень приятно смотреть в базе данных. Для запросов MySQL потребуется много левых соединений для обработки всех дополнительных таблиц CCK, и эти излишне сложные запросы будут слишком часто попадать в медленный журнал запросов. Мне, наконец, надоело пытаться оптимизировать все эти медленные запросы, и я решил избавиться от CCK, что привело меня к PHP-фреймворкам, а затем к Yii.
   Перенос наших данных в Yii занял примерно столько же времени, сколько потребовалось бы, чтобы избавиться от привычки CCK, но остаться на Drupal. Однако мы смогли начать с чистой БД без всех дополнительных таблиц, которые Drupal использует для своих внутренних целей. Наша старая БД имела 173 таблицы; наш новый имеет 54.
7. Drupal намного медленнее, чем Yii . Drupal масштабируется, только если вы кэшируете ВСЁ с помощью memcached и APC и переписываете все медленные запросы. Кэширование особенно важно, если вы используете оптимизированные для SEO переписанные URL-адреса для всех своих ссылок, потому что каждая функция l () является отдельным вызовом базы данных. Таким образом, средняя страница содержит более 50 запросов по сравнению с 3-5 в Yii. После переключения наше среднее время загрузки страницы сократилось с 162 мс до 67 мс согласно инструментам Google для веб-мастеров. Более того, Yii + APC настолько быстр, что нам не нужно использовать memchached, упрощая наш код и операции.

Статистика нашего сервера говорит сама за себя - при одном и том же количестве одновременных запросов посетителей (процессы Apache) загрузка БД и ЦП значительно снизилась. Использование памяти осталось примерно таким же. За последний год наш трафик увеличился на 60% до 1,5 млн. Посещений в месяц, в то время как запросы MySQL сократились на 66%.

Похожие

Комментарии