Читая всякие форумы по CMS-строительству, наблюдаю странную на мой взгляд, картину - люди стараются нагрузить вэб-сервера дурной бесполезной работой, не имея на это никаких существенных оснований. Речь веду о запихивании в БД всего, что под руку попадется. Например, многие современные CMS грешат тем, что хранят в БД те данные, которым там совсем не место - шаблоны страниц, стили и т.д.

Мне кажется, что такой подход - результат того, что вэб-приложения разрабатывают люди, привыкшие создавать софт для настольных систем, для которых хорош принцип "компьютер железный, вот пусть и работает!". Но в вэб такой подход совершенно не приемлем. Имхо. 

Если вы создаете настольное приложение, то вам нет необходимости заботиться о расходе памяти (ее навалом в любом современном компе) равно как и о нагрузке на процессор и т.д. Ведь система однопользовательская и кроме вашей софтины (грубо говоря) ничего на данный момент не выполняется. Работа в фоне всяких торрент-клиентов и винампов не в счет - нагрузка, создаваемая ими минимальна.

Совсем другое дело, когда код выполняется на виртуальном хостинге, где размещена пара сотен сайтов, каждый из которых обслуживает десятки клиентов одновременно. Получается, что параллельно с вашим скриптом сервер обрабатывает еще сотни (а то и тысячи) запросов для других сайтов. Тут уж и кажущиеся несущественные операции дают в сумме дополнительный нагруз, который совсем не так мал, как кажется.

Вот четыре основные вещи, дающие абсолютно лишнюю нагрузку:

1. хранение стилей в БД
2. склеивание стилей в один большой блок
3. хранение шаблонов в БД
4. использование "кросс-БДшного" кода.

Рассмотрим их более подробно.

Проблема хранения стилей в БД.

Модная нынче тенденция хранить стили в БД оборачивается тем, что при каждом запросе клиентского приложения (броузера) серверу приходится запускать PHP-скрипт, который в свою очередь должен пропарсить запрос, определить какие именно стили требуются клиенту, затем "вынуть" их из БД и только потом отправить клиенту, предварительно создав все необходимые заголовки. Казалось бы нагрузка не такая уж и существенная, но все же вариант, когда стили хранятся в отдельных файлах гораздо предпочтительнее, т.к. в этом случае вэб-сервер тупо отсылает клиенту готовый файл и никаких запусков скриптов, парсингов, обращений к БД и прочей лабуды не выполняется. Ну так зачем делать лишнюю работу?

Сторонники хранения стилей в базе данных приводят два (весьма спорных) аргумента в защиту такого подхода.

Первый основывается на том, что пользователи их продукта (CMS) имеют возможность редактировать стили прямо в админке сайта. Круто, конечно, но во-первых редактирование стилей (как и скриптов, шаблонов и прочего не-контекстного барахла) в textarea не идет ни в какое сравнение даже с виндовым "блокнотом". Про всякие подсветки синтаксиса, отступы, автоформатирование, автодополнение и исправление ошибок тут вообще речь не идет. Мазохизм в чистом виде.

Во-вторых, возможность редактирования файлов через админку вовсе не обязует хранить данные в БД — дайте пользователю возможность редактирования через админку стилевых файлов на сервере и обращения к БД (как и бесполезные вызовы скриптов) больше не нужны. Если результат одинаковый, то зачем платить больше?

Опять же, сама возможность такого редактирования может понадобиться только при смене дизайна сайта, а такая необходимость (в реальных условиях серьезного проекта) возникает только на этапе разработки. И для ее выполнения, как ни крути, нужны специалисты (по крайней мере люди, знающие CSS, HTML и т.д.) и уж пользоваться FTP-клиентами и нормальными редакторами такие люди точно умеют. Выходит, что пользы тут ноль.

Второй аргумент — якобы упрощение переноса сайта с одного хоста на другой. Типа просто экспортировали БД на старом хосте и импортировали на новом и все само собой правильно настроилось. Но ведь при переносе сайта вам все равно придется переносить и скрипты (сам код CMS), так какая разница переносить только файлы CMS или файлы CMS плюс файлы дизайна??? Один фиг копировать придется. 

Склеивание стилей в один большой блок.

В сети существует (опять же весьма спорное) мнение, что отправка стилей одним файлом происходит быстрее, чем отправка пачки мелких стилевых файлов. Сторонники этого подхода видимо забывают, что сетевые протоколы по-сути вещи асинхронные и зачастую отправка пачки мелких блоков происходит быстрее, чем отправка одного большого блока, т.к. несколько файлов будут передаваться параллельно и, если какой-то из них где-то вдруг застрянет, то клиенту не придется ждать — он в это время будет скачивать остальные файлы.

В тоже время склейка тоже не происходит сама собой. Снова вэб-сервер, вместо тупой отправки готовых файлов, будет вынужден запускать PHP-скрипты, которым придется производить кучу работы (почти такой же объем вычислений, как при генерации страницы!) — парсить запрос, определять из каких именно шаблонов состоит страница (а для этого придется вызывать все модули, формирующие контент данной страницы, которые, в свою очередь, будут парсить запрос или шаблоны, рыться в БД и т.д.), собирать в кучу (опять же скорее всего из БД) отдельные куски стилевых файлов, клеить их в один и только потом отправлять клиенту. Огромная и совершенно тупая работа и бесполезная нагрузка на сервер.

Хранение шаблонов в БД.

Это наверное наибольший из маразмов, т.к. ни один вменяемый дизайнер/верстальщик ни за какое бабло не станет проводить редактирование шаблонов в броузере. А других аргументов в пользу хранения шаблонов в БД просто нет. Про перенос с хоста на хост я уже сказал, тут тоже никакого выигрыша нет.

Проблема ужесточается тем, что времена когда страница сайта строилась из одного шаблона, давно прошли и ныне страницы современных сайтов собираются из кучи мелких шаблончиков - под каждый блок сайта свой шаблон и, возможно, не один. В результате имеем по одному лишнему обращению к БД на каждый из микро-шаблончиков, а то и более. Зачем? Только чтобы потешить свое ЧСВ, типа идем в ногу со временем и активно используем передовую идею запихивания хлама в БД? Смешно. 

Кросс-БДшные CMS.

Конечно офигенно круто, если ваша CMS может, практически без каких-либо изменений в коде, работать с почти любой, установленной на сервере, СУБД. MySQL? Пожалуйста. Postgre? Легко! MSSQL? Да не вопрос!!! Глобальная победа универсальности в рамках отдельно взятого сайта!

На практике же 80% всех сайтов сидят под MySQL и большего им не нужно. А там где нужны транзакции и прочие мега-фишки, требующие более взрослых СУБД, используются и более другие CMS, заточенные под соответствующие задачи. Зато БД-шная универсальность обходится совсем не так дешево, как кажется. И для программистов и для серверов.

Холиварить тут можно очень долго, поскольку найдется не одна сотня разработчиков, которые будут утверждать, что строить запросы, используя какую-нить ActiveRecord в стопиццот раз проще, чем вручную писать SQL-запросы. Но они лукавят, т.к. если запрос использует пяток таблиц, завязанных перекрестными ссылками в тугой узел, обильно приправленный полу-десятком условий с сортировками, группировками и прочими JOIN'ами, то объем кода, который требуется написать, чтобы все это добро впихнуть в ту же ActiveRecord становится в несколько раз больше, чем сам чистый SQL-запрос. И самое противное, что разобраться в этой мешанине уже совсем не так просто, как в чистом SQL.

В качестве примера, для разминки мозга, можете сами попробовать запрограммировать в ZendFramework или CakePhp вот это (совершенно реальный запрос из моего блога):

SELECT
s.id, inner_uri, category_id, created, last_modified,
title, menu_alt, link_target, author, editor,
COUNT(c.id) as comments,
ua.user_name AS author_name, ua.user_email as author_email,
ua.user_avatar as author_avatar,
ue.user_name AS editor_name, ue.user_email as editor_email,
cat.cat_title AS category , p.content,
p.commenting, p.comment_thru
FROM
t1_module_blog_posts p
LEFT JOIN t1_sitemap s 		ON s.id=p.map_id
LEFT JOIN t1_module_blog_comments c ON c.map_id = s.id
LEFT JOIN t1_users ua 		ON ua.user_id = s.author
LEFT JOIN t1_users ue 		ON ue.user_id = s.editor
LEFT JOIN t1_categories cat	ON s.category_id = cat.cat_id
WHERE
visible=1
AND (s.category_id=0 OR cat.cat_visible=1)
AND (valid_thru=0 OR valid_thru>=1279452356)
AND s.created<1279452356
AND (s.permission='' OR s.permission IN
('admin_panel_access', 'authorized-user', 'developers-only', 'manage_categories',
'manage_content', 'manage_groups', 'manage_menus', 'manage_modules',
'manage_perms', 'manage_prefs', 'manage_settings', 'manage_users', 'module_settings'))
AND (s.category_id IN ('25', '21', '18', '19') 
OR s.category_id=0)
GROUP BY p.map_id
ORDER BY created DESC
LIMIT 20, 140

Сделали? Сравнили читаемость? А заработало? И с первого раза??? 

А теперь прикиньте, что каждый запрос (от простейшего до монстрообразного) требует таких же "напрягов" от вас, как разработчика, а потом еще движок, при каждом обращении к БД будет всю эту вашу писанину парсить, сверять с реальной структурой БД и строить тот самый чистый запрос, от которого вы так долго пытались избавиться который вы так долго пытались "зашифровать" для фреймворка. Работа ради работы?

Ну да, CMS может работать с туевой хучей разных СУБД, но нужно ли вам это в реале? Согласны ли вы платить тормозами за то, чем реально не пользуетесь, ведь из десятка поддерживаемых БД вы все равно пользуетесь только одной?

Итог

Задумайтесь. (С) National Geographic.

 
 

Наконец-то! Ну наконец-то мне в руки попалось это чудо - Adobe Photoshop 12 из пакета CS5! 

Те, кто интересуется этим продуктом, наверное уже знают об основных технических новинках этой версии (а они действительно впечатляют), остальные же пусть курят YouTube - там все и узнают и увидят.

Для меня же главными оказались две вещи:

1. новая версия работает гораздо быстрее предыдущих, обгоняет даже CS3!
2. Теперь Photoshop без труда запускается под Wine'ом в Linux.

Ура, ура, ура! Фотошоп привет, винда прощай!

Ох уж эти переезды! Ну а куда деваться-то, когда в рунете чёрте-что творится? Трекеры торрентов закрывают, у матерых хостеров вроде Agava, ребята в пагонах запросто выносят сервера в неизвестном направлении... Страшно становится за свои сайты. Вдруг и моего, теперь уже экс-хостера (к слову сказать, достаточно надежного и с классным саппортом, рекомендую всем - skyhost.ru) вот так же "вынесут" в неизвестном направлении??? Тьфу-тьфу-тьфу, конечно, но чем уже упоминавшийся чёрт в раше не шутит?

Потому было принято срочное решение по перемещению "активов" в гео-зону с меньшим процентом маразма на единицу населения, а точнее строго в противоположное полушарие.

Примерно два дня было потрачено на выбор хостера - по-сути чтение всяких форумов с отзывами "бывалых" пользователей. Российские представители были отброшены сразу же по вышеописанным причинам. Белорусские пошли в след за Российскими, т.к. соотношение цена/качество у хостеров из Синеокой на два порядка выше, чем в Раше. Следующими были рассмотрены "Украинские варианты". Цены и списки услуг впечатляют - за пару баксов в месяц можно запросто поиметь гектар места со всевозможными прибамбасами. Но... 

Не надо быть экспертом, чтоб заметить, что дизан сайтов, предлагающих самые выгодные тарифы, либо содран с бесплатных шаблонов (а иногда и тупо у конкурентов ), либо сделан школьником-восьмиклассником, прочитавшим первые 7 страниц книги "Научись строить сайты на HTML за 21 день". Лично меня такой подход сильно настораживает - коль крутая фирма не может позволить себе потратить на дизайн своего "кормильца" несчастные пару сотен баксов, значит крутизна тут - чистой воды фикция. Подтверждения моим догадкам тут же нашлись с помощью Гугла - куча отзывов "довольных" (и по большей части уже бывших) клиентов в соответствующих форумах. Так что Украина так же пролетела.

Представителей остальных республик бывшего СССР проверять уже не хотелось - думаю там дела обстоят так же. Потому решил искать счастья на Западе. И первые же варианты ввели в полный ступор.

Прикиньте сами - за 5-8 убитых енотов в месяц вам дадут неограниченное пространство при неограниченном трафике, с неограниченным количеством доменов (суб-, паркованных, дополнительных - любых), при неограниченном количестве БД, почтовых и FTP-аккаунтов, куче скриптов, всевозможной статистике, и прочем, и прочем, и прочем... 

При таком раскладе тарифные планы вообще-то теряют всякий смысл, ведь у всех и так всего навалом. Так что некоторые хостеры просто выкинули со своих сайтов все эти заморочки с тарифами (типа "сравнение планов", VIP-услуги и прочую фигню) и оставили только форму регистрации - один тарифный план для всех. Плюс скидка, в зависимости от срока на который покупается хостинг. И все!

М-да.... Давненько я не изучал предложения от англо-говорящих хостеров - оказывается многое в мире изменилось за это время. А я, как дурак имел за эти же деньги несчастные 200 мегабайт + 1 БД + 2 доп. домена... Нет, денег не жалко - чего тут жалеть-то, просто обидно. Чувствую себя в очередной раз обманутым... 

Ну так вот, посмотрев около пяти различных модных западных хостеров, и поняв, что они ничем в принципе не отличаются и (для собственного успокоения) почитав немного обсуждения на соответствующих форумах, остановил-таки свой выбор на одном представителе. И вот почему.

1. На самом дешевом тарифном плане вы получаете 3Гб места + 30Гб трафика
2. Нет ограничений на нагрузку на сервер (как у многих украинских хостеров)
3. Нет ограничений на количество суб- и дополнительных доменов (можете развернуть сколько угодно сайтов на одном аккаунте)
4. Нет больше вообще никаких ограничений (всякие SSL и выделенные IP меня не интересуют)
5. Стоит это удовольствие всего $40 в год!

Собственно для меня этих пяти причин оказалось достаточно, что бы сделать заказ. На оформление ушло пара минут, еще минут пять на "серверную магию" и вуаля - полностью работоспособный хостинг у меня в полном распоряжении. Пока переливал сайты со старого хоста, успели обновиться DNSы и это сообщение пишу уже на новом хостинге.

Конечно возможно, что со временем обнаружатся какие-нить косяки, но первые часы работы на новом месте доставляют только радость. Так что если тоже ищете куда бы перепрятать свои сайты, вилком в нашу компанию - давите на ссылку и регистрируйте гектары для ваших новостроек.