Fast Drupal Distribution [что скажет сообщество?]

Главные вкладки

Аватар пользователя seaji seaji 20 января 2009 в 13:10

Привет всем!

Возникла идея создать стартап.
Главным слоганом будет "Друпал с человеческим лицом".
Сейчас объясню подробнее. Все ведь знают такую конторку как Аквиа? Чем она занимается? Берется Друпал и расширяется дополнительными модулями, ну там CCK, Views, Image Field, и т.д. Все это дело распространяется отдельными дистрибутивами.

Я же предлагаю совершит обратное действие. Не расширять Друпал, а наоборот его урезать, упростить в угоду производительности.
Пока есть мысли отказаться от таких вещей, как:
Форматы ввода
Статистика
Может быть что то еще.

Возможно имеет смысл пересмотреть логику вывода материалов. Сделать несколько патчей ядра.
И конечно, ни каких Views и CCK.

Предполагаю сделать несколько, узко заточенных дистрибутивов: блог/коллективные блоги, сайт визитка, новостной сайт, интернет магазин и пр.

Что скажет сообщество по этому поводу? Имеет ли смысл? А если имеет, то какие именно аспекты нужно упрощать?

Комментарии

Аватар пользователя evgenioni@drupal.org evgenioni@drupal.org 20 января 2009 в 14:12

Я думаю что стандартная поставка друпала вполне адекватна и сбалансирована. Я в друпале совсем чайник, коллективный блог/магазин я конечно не поднимал, но более-менее рабочий вариант сайта-визитки сделал за пару вечеров и часов 6 в сумме, начиная с поиска "на чем ваять" заканчивая функционалом и худо-бедно шаблоном. Чтобы все довести до победы уйдет, конечно, немало времени, но визитка на основе открытых шаблонов и модулей меня пока вполне устроит. Потом оценю вложения-отдачу и найму человека или фирму, чтобы сделала "как надо". Сейчас спасает знание английского и немного кодирования/верстки.
Сейчас я думаю, что основная проблема - это отсутствие пошаговых мануалов и описания самых необходимых модулей. В стиле "вам нужно это? тогда есть вот такой и такой модуль, нажмите сюда и сюда..." Для меня, например, проблема - хороший файловый менеджер, imce и webfm кривые какие-то и неудобные, альтернатив не знаю.
Еще будут полезны готовые стандартные профили, или как они называются... вобщем чтобы сразу ставился определенный набор модулей. И самое главное - вся инфа должна быть в одном месте, разделе, и, желательно, на этом сайте.
Это мое мнение, человека, которому нужно оперативно и быстро поднять простенький сайт, и самое главное - отсутствие времени на поиск информации. Так же я думаю, что такой подход будет очень полезен для сообщества с точки зрения маркетинга. Базовый функционал запускается самостоятельно, поддержка-доработка на стороне.

PS Дистрибутивы требуют затрат на сопровождение, не будете же вы просто их делать и не сопровождать? Иначе смысл в них. По моему, с точки зрения затрат сгруппированная информация в ввиде визарда тоже предпочтительней.

Аватар пользователя Stan.Ezersky Stan.Ezersky 20 января 2009 в 14:07

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

К тому же, это лишает всех прелестей изучения друпала (по крайней мере, говорю про себя, как начинающего с друпалом)

Аватар пользователя sadmin sadmin 20 января 2009 в 14:28

Идея интересна, особенно если будут люди, поддерживающие эти дистрибутивы. Но работы очень много.

Аватар пользователя gorr gorr 20 января 2009 в 14:37

Статистику можно не включать просто. Форматы ввода восновном нужны. Ядро друпала итак стараются не раздувать, при этом сохраняя гибкость. Какие патчи имеются ввиду?

Аватар пользователя seaji seaji 20 января 2009 в 14:58

Как раз идея в том, что бы избавиться от гибкости в пределах разумного.

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

Аватар пользователя AlexanderDN AlexanderDN 20 января 2009 в 19:26

Интересно с точки зрения опыта сборки. Если будете делать - очень будет интересно узнать как и что.

Сейчас сам думаю о том, чтобы сделать свою сборку. У меня правда, немного другая идея компановки. Есть группа модулей, которые использую практически во всех проектах(и views и cck туда входят, как и bueditor,imagecache и др.). Пока просто времени нет глянуть на доки по сборке своего инсталлятора. Но думаю, через недельки две, как с текущими делами покончу, займусь. Я Вас в букмарки добавил, тогда отпишусь как начну делать и будет конкретика. Может чем друг другу поможем Smile

Аватар пользователя axel axel 20 января 2009 в 20:02

А можно выкинуть поддержку языков. Метод я как-то тут описывал - проходим скриптом по ядру и подменяем t("") на статические строки с переводом. Получаем жёстко "локализованный" движок. Нужен другой перевод? Берём оригинальный код и снова проходим по нему скриптом, указав откуда брать переводы. Правда сложнее с параметрами передаваемыми в строках переводов, но тоже можно обойти.

Аватар пользователя rbogdan@drupal.org rbogdan@drupal.org 26 января 2009 в 16:24

axel wrote:
А можно выкинуть поддержку языков. Метод я как-то тут описывал - проходим скриптом по ядру и подменяем t("") на статические строки с переводом. Получаем жёстко "локализованный" движок. Нужен другой перевод? Берём оригинальный код и снова проходим по нему скриптом, указав откуда брать переводы. Правда сложнее с параметрами передаваемыми в строках переводов, но тоже можно обойти.

Если создать такой модуль, то можно сберечь кучу ресурсов, ведь как раз на перевод функций t() тратится 70-80% ресурсов. Получается сразу выигрыш производительности в минимум 2-3 раза. И многие "тяжелые" модули будет "летать". Даже думал взять, эту тему как тему дипломной работы, только проблема сейчас на 4 курсе, а модуль нужен всем.

Аватар пользователя axel axel 21 января 2009 в 1:36

Razunter wrote:
Может, всё выкинем, кроме readme? Будет очень быстро работать, багов не будет...

Дельная мысль!

Аватар пользователя kolen kolen 20 января 2009 в 21:57

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

Для блогов даже лучше что-то типа "Drupal Livejournal migration pack" -- для тех, кто валит с ЖЖ на стенделоун :). С фичами, характерными для ЖЖ -- похожие комменты, опенид, кросспостинг в ЖЖ для тех, кто не совсем свалил.

Аватар пользователя seaji seaji 20 января 2009 в 22:29

Спасибо всем, кто откликнулся.
Собратья! У меня просьба. Если у кого есть ссылки на патчи, которые ускоряют работу, то кидайте их тут в комментах.

Аватар пользователя mozaic mozaic 21 января 2009 в 4:35

Вячеслав, идею вашу целиком поддерживаю !

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

Это примерно как с осью - кому нужно готовое решение - ставят винду, кому нет - сами знаете что ...

Как раз с готовыми решениями \ сборками у Друпала проблема, поэтому, на мой взгляд, будет очень здорово если таковые появятся.

Да - не поленитесь - выложите эту идею на Друпал.орг - посмотрите тамошнюю реакцию. Вообщем - за идею 5.

Убрать статистику и сделать жесткую локализацию - поддерживаю.

Да - отдельный вопрос - смогут ли такие урезанные сборки поддерживать:

  • автоматическое обновление
  • установку при необходимости дополнительных модулей

Появятся еще мысли - обязательно поделюсь, это пока первая реакция.

Давайте только определимся - где это делать - в комментах сюда или иожет на форуме отдельную ветку создадим ?
Успехов !

Аватар пользователя direqtor direqtor 21 января 2009 в 7:29

Я бы многое хотел бы по этому поводу...
а) Оставить ноду только узлом с nid - все требуемые поля добавлять через CCK.
б) Полную поддержку многоязычности на уровне полей.
в) Оптимизировать структуру таблиц для полей ноды. Для каждого типа нод вести четыре таблицы для полей: однозначные-многоязычные (т.е. одинаковые для всех языковых версий ноды), однозначные-одноязычные, многозначные-одноязычные (т. е. для каждого языка свои) и многозначные-многоязычные. Это позволит выбирать всю информацию ноды максимум четырьмя запросами.
г) Тизеры и фулноды - фтопку: полностью настраивать с нуля представления ноды в любом количестве. Для каждого представления формировать сразу VIEW в БД и нужную информацию выбирать из него разом только по nid и идентификатору языка.
д) Убрать порочную практику использования строк в качестве первичных ключей в БД. Например языки.
г) Превратить таксономию в ноды - использовать nodereference для связи между нодами-категориями и нодами-материалами. Каменты модифицировать таким же образом.

Т.е «голый» друпал в таком случае должен представлять из себя только менюрутер и систему авторизации. Остальное настраивается с нуля.
Правда, без сборок тут уже не обойтись.
Не много ли я хочу?

Аватар пользователя tema tema 21 января 2009 в 9:30

имхо форки - это зло в чистом виде.
уверены, что не отстанете от паровоза? обычная судьба форков - потеря внимания общественности из-за плохой поддержки и отсутствия новых версий.

Аватар пользователя seaji seaji 21 января 2009 в 11:14

"tema" wrote:
плохой поддержки и отсутствия новых версий

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

Аватар пользователя Irbis Irbis 21 января 2009 в 11:39

Была идея на эту тему.

1. Готовые поставки - т.е. сборки оптимизированные под конечные задачи + инструкция. Установил - вот тебе сайт визитка, или готовый магазин - всё включено, осталось только добавить информацию. По общению с непрофильным народом (не программеры), многим такого не хватает. Делал под заказ такие сборки пару раз с инструкциями краткими.

2. 100% перевод всех модулей сборки.

3. Разбивка логики на 4 секции с возможностью разноса на разные серверы:
- Генерирующие блок
- Кэширующий (отдающий) блок (на подобии cacherouter в ядре)
- Файло-отдающий блок (для хранения статического контента)
- Распределяющий блок (с 3 уровневой програмной-авторизацией, на подобии кэша авторизации + авторизация Drupal (СТРИМ24 по подобной схеме авторизации работает, только он не на Drupal Lol
4. Полный аудит кода + патчи для ускорения работы (на подобии - убить перевод и т.п.)

По идее такие форки будут работать быстрее но будут не такие гибкие как Drupal и их следует рассматривать не как форки, а как расширение линейки Drupal (на подобии Windows XP Home, Windows XP Pro).

У меня не стартап, самому это добро нужно будет.

Пока это всё в планах на осень 2009, пока некогда скины к Lazarus прикручиваю:)

Аватар пользователя Demimurych Demimurych 21 января 2009 в 11:40

Мне кажется
Не этим нужно заниматься.

Нужна нормальная документация на русском языке. Где бы доходчиво обьясняли как правильно работать с друпал. Тогда необходимости в таком велосипеде не будет.

Аватар пользователя seaji seaji 21 января 2009 в 11:48

Простите, документация тут не поможет (я имею ввиду ускорение Друпала).
Когда я смотрю сколько и какие запросы выполняются при генерации страницы у меня сердце кровью обливается.

Аватар пользователя neochief neochief 22 января 2009 в 14:17

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

Аватар пользователя Irbis Irbis 22 января 2009 в 14:24

Жене понравилось, как начинающему программеру. Правда она долго смеялась на переводом слова AJAX - переведено как: АНАН. Программисты Delphi - дельфисты, а програмисты АНАН - кто тогда? Smile

Аватар пользователя penexe penexe 22 января 2009 в 16:00

Irbis wrote:
Жене понравилось, как начинающему программеру. Правда она долго смеялась на переводом слова AJAX - переведено как: АНАН. Программисты Delphi - дельфисты, а програмисты АНАН - кто тогда? :)

а точно там AHAH был как перевод AJAX а не Asynchronous HTML and HTTP ?

Аватар пользователя Stasroot1@drupal.org Stasroot1@drupal.org 22 января 2009 в 15:00

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

Аватар пользователя neochief neochief 22 января 2009 в 15:49

"хуки", "ноды" и "триггеры". Конечно есть люди, которые приведут аргументы о "чистоте русского языка". Но они в данном случае совсем не к месту по двум причинам:
1. Все разработчики, которых я знаю (а их немало), пользуются именно словами "нода", "хук" и т.п.
2. Когда потом программисту, выучившемуся на "ловушках" и "переключателях" надо будет найти на drupa.org информацию, он столкнется с баръером непонимания.

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

Аватар пользователя andypost@drupal.org andypost@drupal.org 23 января 2009 в 7:07

Объективно, полезно просто сделать сборку ядра + перевод.

Предпочитаю хранить дампы установленных версий, разворачивать намного быстрее...

Сборка сама-по-себе - это не о чем. Модули довольно часто обновляются, а порой требуют изменений для корректной работы.

cck views и прочие, еще чистить и чистить (в плане перевода строк, не говоря уже о прилагаемых к ним html справках).

Что касается патчей-ускорителей - таких волшебных таблеток нет и быть не может, по одной простой причине - оптимизация каждого сайта отлична от других и, если уж найдена какая-то проблема или альтернативный путь, то это дело нужно на d.o посылать и там дискутировать.

Аватар пользователя TheRuslan TheRuslan 24 января 2009 в 5:33

Инициатива вещь хорошая, но.. думаю, не туда вы силы хотите бросить.
Зачем катить проект назад. Создавайте большее, не шагайте назад.
Прививайте людям стремление разбираться, развиваться, создавать что-то стоящее.
Помогайте в ЭТОМ. Не наоборот.

Аватар пользователя alexandr.poddubsky alexandr.poddubsky 24 января 2009 в 13:40

"neochief" wrote:
"хуки", "ноды" и "триггеры". Конечно есть люди, которые приведут аргументы о "чистоте русского языка". Но они в данном случае совсем не к месту по двум причинам:
1. Все разработчики, которых я знаю (а их немало), пользуются именно словами "нода", "хук" и т.п.
2. Когда потом программисту, выучившемуся на "ловушках" и "переключателях" надо будет найти на drupa.org информацию, он столкнется с баръером непонимания.

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

Ага,полностью согласен! правильно! зачем переводить слова, которые были заимствованы не из русского языка.

Аватар пользователя vasyapupkin1 vasyapupkin1 24 января 2009 в 16:06

"seaji" wrote:

Понимаете, мне самому будет легче и быстрей поднимать сайты из таких сборок.

Конечно легче, кто ж спорит?

"seaji" wrote:

Не говоря уже о том, что такие вещи легко монетизировать.

Какие вещи? Зачем мрнетизировать?
Всё и вся монетизировать не наша задача.

"seaji" wrote:

По этому, новые версии это не проблема, а за поддержку можно и монетку брать.

По-моему, как раз проблема. Коммерческая поддержка ВАШЕГО продукта - дело ваше, но причём здесь Drupal сообщество?
"Давайте заоптимизируем код друпала так шобы он летал на narod.ru и не использовал БД в принципе (вот была бы вещь), а вы потом платите мне денюжку за поддержку"...

В инете и так полно воплей по поводу "кошмарной грузности и тяжёлости" Drupal - и это никак не мешает развиваться ни самому Drupal, ни сообществу, ни многочисленным известным сайтам, использующим Drupal.
Может стоит вырасти из уровня "монетизации и создания сайтов под сапу на говнохостингах ЗАДЁШЕВО" и поставить свои сайты на Drupal на нормальный хостинг или vds или dedicated (если сайтов много)?
Тогда и миграция с версии на версию, добавление новой функциональности, да всё что угодно, будет делом приятным, не отбременительным и совершенно бесплатным (если голова на плечах есть)
Вот за это я готов сказать "Благо Дарю" и opensource и Drupal и сообществу.
Пардонте, если резковато.

Аватар пользователя seaji seaji 25 января 2009 в 15:23

"vitich" wrote:
Вот за это я готов сказать "Благо Дарю" и opensource и Drupal и сообществу.
Пардонте, если резковато.

Да уж, есть немного Smile
Однако Ваши высказывания имеют мало ценности. Знаете почему?
Что вы сами сделали для сообщества? Кроме того, что сказали "Благо Дарю"??
Много ли людей высказали благодарность именно Вам?

Аватар пользователя EllECTRONC EllECTRONC 25 января 2009 в 16:18

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

"seaji" wrote:
Понимаете, мне самому будет легче и быстрей поднимать сайты из таких сборок. Не говоря уже о том, что такие вещи легко монетизировать. По этому, новые версии это не проблема, а за поддержку можно и монетку брать.

Для многих проще заказать сайт от и до и не мучится самомму. Кто захочет разбираться с движком да еще за деньги, когда можно один раз заплатить и спать спокойно.
"Demimurych" wrote:
Нужна нормальная документация на русском языке. Где бы доходчиво обьясняли как правильно работать с друпал. Тогда необходимости в таком велосипеде не будет.

документации много, но проблема в другом, люди не хотят читать маны, а предпочитают инструкции и при этом не хотят их искать. "Лень захватила молодое поколение!" ©

Аватар пользователя direqtor direqtor 25 января 2009 в 16:59

"EllECTRONC" wrote:
"Лень захватила молодое поколение!" ©
ППКС.
Вопрос, который задают после первого error message - это не вопрос, а нежелание что-то сделать самому.

Аватар пользователя neochief neochief 26 января 2009 в 21:49

"<a href="mailto:rbogdan@drupal.org">rbogdan@drupal.org</a>" wrote:
перевод функций t() тратится 70-80% ресурсов

Не надо разводить слухи и суеверия. Эти цифры значительно меньше.

Аватар пользователя seaji seaji 26 января 2009 в 22:09

Да, да, цифры действительно меньше.
Там сейчас на это дело кеш стоит. Однако какая то часть памяти и ресурсов тратится.

Аватар пользователя PavelZ PavelZ 4 февраля 2009 в 16:48

Проблемы перевода терминологии и вопросы облегчения Капли стары как мир.
Использую в основном для своих работ Joomla http://shalasha.net (1.0) http://khaber.ru (1.5), на Drupal делал один тестовый проект, специально без дополнительных модулей, на разных хостингах ставил, везде свои нюансы и если Joomla считающаяся тоже тормозом, ставится и работает почти без проблем, то здесь не всё так гладко, то памяти не хватает, то библиотеки нет.
В то же время разрабатываю новый проект на локальной машине именно на Drupal не из упрямства, что мол одолею я его или он меня, ни в коем случае это не так.
Именно возможность сваять то, что задумано, а не подстраивать свою идею под имеющиеся рамки как в Joomla, не смотря на то, что за это приходится платить более высокими требованиями к серверу -- главная ценность Drupal. Идею сделать облегчённую сборку считаю абсурдом. Для визиток есть другие инструменты, опытный Web мастер может выбрать пяток движков (инструментов) и не парится пытаясь одними пассатижами гвозди забивать, кусать проволоку и откручивать шурупы, проще всё же взять молоток отвёртку и бокорезы.

Аватар пользователя direqtor direqtor 5 февраля 2009 в 20:04

"PavelZ" wrote:
Именно возможность сваять то, что задумано, а не подстраивать свою идею под имеющиеся рамки
Тоже это ценю больше всего. Простота интеграции ЛЮБОГО своего кода в друпал - это для меня главное.

Хотя и у него есть рамки - API...

Аватар пользователя EllECTRONC EllECTRONC 14 февраля 2009 в 0:27

"kwas" wrote:
Друпал. Для этого есть другие движки и их много.

Примерчик не подкините? Но только не забудьте про функциональность.

Аватар пользователя kwas kwas 14 февраля 2009 в 1:00

Основная идея была именно в отказе от функциональности ради скорости и снижения требовательности к ресурсам сервера.
Пример - NanoCMS или как её там, CMS от Ласто
Показывает свободные от оформления хтмэльки в нужном дизайне. Так же как и CMSimple, позволяет иметь отдельные дизайны хоть для каждой страницы.
Danneo, XOOPS, MODx. Правда, в последней много ручной работы требуется, но тоже приятная.

Аватар пользователя EllECTRONC EllECTRONC 14 февраля 2009 в 1:15

XOOPS, MODx -- пробовала — хавно, MODx и CMS назвать сложно! CMSimple... вроде тоже пробовала... или еще нет...

"kwas" wrote:
Основная идея была именно в отказе от функциональности ради скорости и снижения требовательности к ресурсам сервера.

Короче сравниваем бегемота и кролика — глупо.

Аватар пользователя seaji seaji 17 февраля 2009 в 21:33

Почему то пришла в голову мысль собирать код всех включенных модулей в один файл автоматом при включении\выключении модулей. И подключать его одним запросом.

Аватар пользователя gorr gorr 18 февраля 2009 в 13:31

seaji wrote:
Почему то пришла в голову мысль собирать код всех включенных модулей в один файл автоматом при включении\выключении модулей. И подключать его одним запросом.

Да, это может ускорить загрузку друпала, но в 6-ке реализована система так, что при запросе к серверу подключаются файлы, наподобие 'file' => 'taxonomy.pages.inc', в которых находится код, необходимый только на данных страницах, а на других он не нужен, как с ними тогда поступить? Не утяжелит ли наоборот это систему, если их все в один файл?

Аватар пользователя seaji seaji 18 февраля 2009 в 14:53

Моск уже выносит.
исправил common.inc
<?php
require_once './includes/theme.inc';
require_once './includes/pager.inc';
require_once './includes/menu.inc';
require_once './includes/tablesort.inc';
require_once './includes/file.inc';
require_once './includes/unicode.inc';
require_once './includes/image.inc';
require_once './includes/form.inc';
?>
Все это перенес в один файл и подключил одной командой.
Разницы ни какой!!!!!
Как было 25 - 30 миллисекунд так и осталось.
Больше всего бесит, что подключение через require_once всех включенных модулей у меня занимает половину от времени создания страницы 700 - 800 миллисекунд.
И причем самые "тормоза" это системные модули: user, node, comment, forum.
На эту четверку уходит ну одна треть времени точно. Всего модулей подключается 70.
Могу привести время подключения каждого файла.
Уже не знаю, может не запариваться со слиянием файлов в один???
Такое ощущение, что require_once отнимает не много времени, в основном время тратиться на парсинг.
Так ли это?

Аватар пользователя gorr gorr 18 февраля 2009 в 16:55

да, require_once затратная операция, намного менее затратна require либо include, попробуйте, но нужно следить, чтобы вызывалось в одном месте самому.

Аватар пользователя seaji seaji 18 февраля 2009 в 20:19

"gorr" wrote:
require_once затратная операция

Пробовал и то и другое и пятое и десятое, все одно и то же. Sad

Мне не понятно одно.
Почему 60 файлов модулей инклюдятся от 1 до 10 мс.
А 10 модулей инклюдятся за 50 - 100 мс.

От чего это зависит? От количества функций и переменных?

Аватар пользователя seaji seaji 19 февраля 2009 в 1:43

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
Вообще при установне APC eAccelerator - этих проблем не должно быть

Не, не APC, не eAccelerator нету.

Аватар пользователя andypost@drupal.org andypost@drupal.org 19 февраля 2009 в 1:45

А как можно столько модулей запускать без них? Это абсурд - половину времени обработки страницы будет уходить именно на компиляциюю скриптов...

Аватар пользователя seaji seaji 19 февраля 2009 в 1:53

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
Это абсурд - половину времени обработки страницы будет уходить именно на компиляциюю скриптов...

Ага, так оно и есть. См. сюда: http://drupal.ru/node/25121

Аватар пользователя kosilko kosilko 19 февраля 2009 в 5:09

"seaji" wrote:
И причем самые "тормоза" это системные модули: user, node, comment, forum.

user,node - весят под сто килограм каждый. Все это процессорное время, парсинг функций, переменных. Размашистые комменты к каждому хуку/функции, набросанные щедрой рукой =)... Лучше конечно, eAccelerator поставить и не париться.

Аватар пользователя Anodonta Anodonta 25 марта 2009 в 12:20

Думаю, это не разумно.
Я сюда пришёл после долгих выборов между различными способами построения сайта.
А читая Ваше предложение "облегчить друпал" может создаться мнение, что я сделал неправильный свой выбор на Друпал.
Не нужно "облегчать друпал", - нужно не жадничать на хостинг.

Аватар пользователя kwas kwas 25 марта 2009 в 13:49

"Anodonta" wrote:
Не нужно "облегчать друпал", - нужно не жадничать на хостинг.

Сколько Вы платите за хостинг, на котором Друпал чувствует себя свободно?

Аватар пользователя Stan.Ezersky Stan.Ezersky 28 марта 2009 в 18:08

"kwas" wrote:
Сколько Вы платите за хостинг, на котором Друпал чувствует себя свободно?

1160 руб в год. FFMPEG не пользуюсь, причём это виртуальный хостинг, а не сервер -)

Аватар пользователя Stan.Ezersky Stan.Ezersky 29 марта 2009 в 12:33

"kwas" wrote:
странненько. за такие деньги обычно предлагают хостинг похуже, чем обычный бесплатный

У меня работает всё, правда у меня всего 1гб места, но анлим трафик, доступ ко всем настройкам, CPanel, анлимы на базы, почту, фильтры

Аватар пользователя Stan.Ezersky Stan.Ezersky 29 марта 2009 в 12:56

ОФФТОП
Господа, поймите правильно, к тому же, никого не хочу обидеть, но вот что я думаю.

Вы не изобретаете велосипед? Почему не взять какой-нибудь фреймворк и не написать проект на нём? Здесь, за время моего нахождения в сообществе Друпал.ру, я увидел кучу отличных программеров. Возьмите Зенд, КИ, Симфони (или кучу других), в которых есть ООП (!) и написание модулей не составляет для профи никакого труда.

По поводу сборки: из песни слов не выкинешь. Что-то доставить (или интегрировать своё) можно, но менее прожорливым Друпал не станет. Сделать сборку, которую можно поставить не подготовленному человеку не получится. В Друпал надо вникнуть и делается это не за один день. Вспомните вопросы в коммьюните "как поставить?"...

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

Прошу не воспринимать это как критику на автора идеи и людей его поддержавшего, просто я не понимаю зачем.

P.S. Для меня работа с Друпалом какой-то культ, только под Друпал я пишу подробное ТЗ самому себе, чего никогда не делал под ВордПресс. С Друпалом интересно работать с нуля.

Аватар пользователя EllECTRONC EllECTRONC 29 марта 2009 в 16:45

"EzS" wrote:
С Друпалом интересно работать с нуля.

Не всем это интересно, многие просто привыкли — поставил —> работает —> забыл. Сборки рассчитаны на конечных пользователей, которые ничего кроме как пользоваться не будут.
Отсюда вытекает то, что программеру или тому, кому интересно самому — это не будет так же интересно.