Начну свой первый пост с маленькой заметочки о Drupal, который я недавно начал использовать, а также в который я влюбился и одновременно разочаровался. Влюбился по причине наличия необъятной широты возможностей, которые дает этот движок. Куча модулей, приятная архитектура для программиста (чтобы доработать напильником или написать свой модуль), невероятная гибкость — все это не оставит равнодушным, как, в прочем, и то, как все это хозяйство начинает тормозить при разрастании!
Был у меня сайт и решил я его освежить при помощи современного комьюнити-ориентированного движка, которым и является Drupal. Сайт был самописный, простой. Работал быстро, т.к. использовал кэширование в статику и отдачу этой статики на nginx. Было у него достоинство — человекопонятные URL-адреса (ЧПУ). При переводе на Drupal потребовалось использовать модуль Path, входящий в стандартную поставку, для воссоздания ЧПУ на сайте. Это привело к тому, что при формировании страницы происходит: — для главной 400-600 запросов в базу; — для вложенной 200-400 запросов в базу. Drupal ищет для каждого тэга таксономии свой алиас в базе URL-адресов.
При малом количестве тэгов в базе ситуацию можно исправить правкой кода модуля таким образом, чтобы тот осуществлял получение всей таблицы алиасов одним запросом. Но когда база разрастается и начинает включать весь словарный запас тематики сайта, тут уже ничего не попишешь…
Дополнительные проблемы появляются у Drupal'а при обрастании модулями. На виртуальном хостинге может не хватить лимита в 16Мб для PHP. Если кто знает виртуальный хостинг с лимитом в 32Мб, дайте знать! На VPS разросшийся Drupal работает медленно из-за болтающейся на том же VPS базе MySQL. Выйти из положения можно разнесением Drupal и MySQL на разные хосты (MySQL можно держать на виртуальном хостинге — там под нее обычно выделен отдельный сервер). Кто-то скажет, что надо брать отдельный сервер, но для этого проект должен хотя бы окупаться, а на Drupal обычно делают любительские проекты, иной раз вовсе не приносящие прибыль, а существующие для души.
Резюме на последок
На Drupal лучше всего делать проекты с нуля, сохраняя его внутреннюю человеконепонятную адресацию. Заранее нужно продумать структуру сайта, чтобы понять, какие модули необходимо будет использовать. Если Вы планируете проект с высокой посещаемостью, то рассмотрите вариант «написать свой движок», т.к. на оптимизацию Drupal в последствие Вы потратите времени уж точно не меньше.
Был у меня сайт и решил я его освежить при помощи современного комьюнити-ориентированного движка, которым и является Drupal. Сайт был самописный, простой. Работал быстро, т.к. использовал кэширование в статику и отдачу этой статики на nginx. Было у него достоинство — человекопонятные URL-адреса (ЧПУ). При переводе на Drupal потребовалось использовать модуль Path, входящий в стандартную поставку, для воссоздания ЧПУ на сайте. Это привело к тому, что при формировании страницы происходит: — для главной 400-600 запросов в базу; — для вложенной 200-400 запросов в базу. Drupal ищет для каждого тэга таксономии свой алиас в базе URL-адресов.
При малом количестве тэгов в базе ситуацию можно исправить правкой кода модуля таким образом, чтобы тот осуществлял получение всей таблицы алиасов одним запросом. Но когда база разрастается и начинает включать весь словарный запас тематики сайта, тут уже ничего не попишешь…
Дополнительные проблемы появляются у Drupal'а при обрастании модулями. На виртуальном хостинге может не хватить лимита в 16Мб для PHP. Если кто знает виртуальный хостинг с лимитом в 32Мб, дайте знать! На VPS разросшийся Drupal работает медленно из-за болтающейся на том же VPS базе MySQL. Выйти из положения можно разнесением Drupal и MySQL на разные хосты (MySQL можно держать на виртуальном хостинге — там под нее обычно выделен отдельный сервер). Кто-то скажет, что надо брать отдельный сервер, но для этого проект должен хотя бы окупаться, а на Drupal обычно делают любительские проекты, иной раз вовсе не приносящие прибыль, а существующие для души.
Резюме на последок
На Drupal лучше всего делать проекты с нуля, сохраняя его внутреннюю человеконепонятную адресацию. Заранее нужно продумать структуру сайта, чтобы понять, какие модули необходимо будет использовать. Если Вы планируете проект с высокой посещаемостью, то рассмотрите вариант «написать свой движок», т.к. на оптимизацию Drupal в последствие Вы потратите времени уж точно не меньше.
