Drupal быть или не быть.

С чего начать Drupal 6 или Drupal 7 ?

  • Drupal 6

    Голосов: 2 28,6%
  • Drupal 7

    Голосов: 5 71,4%

  • Всего проголосовало
    7
  • Опрос закрыт .
Статус
В этой теме нельзя размещать новые ответы.
Кстати говоря многочисленные уверения в топике о низкой производительности Drupal, говорят лишь о том, что очень немногие с ней реально работают. И немного имеют посещаемые проекты хоть на чем нибудь. Либо они писали(либо брали) для drupal, какие-то модули, которые не используют встроенные механизмы оптимизации, кеширования.
Выигрыш в производительности по сравнению с самописной CMS чаще достаточно маленький. А удобство намного выше, я уже не говорю о достаточно высоком уровне безопасности, который слабо достижим для самописных CMS.

Есть конечно исключения, где нужна своя CMS, но они чертовски редки.
 
Кстати говоря многочисленные уверения в топике о низкой производительности Drupal, говорят лишь о том, что очень немногие с ней реально работают. И немного имеют посещаемые проекты хоть на чем нибудь. Либо они писали(либо брали) для drupal, какие-то модули, которые не используют встроенные механизмы оптимизации, кеширования.
Выигрыш в производительности по сравнению с самописной CMS чаще достаточно маленький. А удобство намного выше, я уже не говорю о достаточно высоком уровне безопасности, который слабо достижим для самописных CMS.

Есть конечно исключения, где нужна своя CMS, но они чертовски редки.
Отчасти вы правы, но:
Друпал на самом деле генерит много запросов. Другое дело, что есть разница между т.н. "короткими и длинными" запросами (а у Друпала они отпимизированы в сторону исключения длинных) и настройками кэширования (которые тоже довольно мощны у Друпала).
 
Отчасти вы правы, но:
Друпал на самом деле генерит много запросов. Другое дело, что есть разница между т.н. "короткими и длинными" запросами (а у Друпала они отпимизированы в сторону исключения длинных) и настройками кэширования (которые тоже довольно мощны у Друпала).
Я не понял, что из этого противоречит моим словам. А измерять производительность количеством запросов вообще глупость, которую непонятно кто придумал.
 
количество запросов это количество время генерации данных. Недавно был на конференции у Яндекса так они рассказывали как оптимизируют свой шаблон и одно из главный направления один CSS стиль они объяснили чем больше подключения css стилей то больше время обработки не зависимо от их объема , а объем уже на втором месте и за этого они сначала делают около 13 стилей для каждого браузера потом с помощью утилиты обедняют их и получают на выходи один стиль с полностью жатым и чистым кодом.
А по запросом в БД могу вам вот что сказать что быстрее будет 1 запрос или равно сильных 100 ? Я вам сразу отвечу 1 . а теперь смотрите друпал 6.х делает около 52 стандартных запросов . Из них примерно 70% лишних для сайт визиток. Тогда как вордпресс делает порядка 13 запросов.
уже видно что десятую а может даже несколько дясятых частей от секунды можем выграть только на запросах. Потом хеширование и оптимизация CSS листов и + к этому пережать графику и получаем почти максимальную производительность можно было бы канешно еще на JS повесить шаблон и загрузку графики но это для сайт визиток не нужно.
И финал Берем самый самый дешевой хостинг и проверяем на нем ДРУПАЛ со всеми манипуляциями загрузка будет примерно средняя . 0.6 до 1.1 секунд тогда как на вордпресс будет примерно 0.3 - 0.8 секунд.

Но это мои тесты. Но еще есть одна хитрость если нужна производительность то берем фреймворк YII и все пишем что нам нужно. Там скорость будет еще выше.Так как все запросы мы сами пишем. Кешируем тоже что нам нужно
 
А по запросом в БД могу вам вот что сказать что быстрее будет 1 запрос или равно сильных 100 ? Я вам сразу отвечу 1 .
Вы ответите не подумав. Если у вас на сайте одна страница и нет кэширования, то да генерация будет быстрее если использовать один запрос. Но выигрыш будет минимален. Совсем. Если появится кэширование, то вы так и будете, уныло выполнять один этот запрос.

количество запросов это количество время генерации данных.
Что?

Недавно был на конференции у Яндекса так они рассказывали как оптимизируют свой шаблон и одно из главный направления один CSS стиль они объяснили чем больше подключения css стилей то больше время обработки не зависимо от их объема , а объем уже на втором месте и за этого они сначала делают около 13 стилей для каждого браузера потом с помощью утилиты обедняют их и получают на выходи один стиль с полностью жатым и чистым кодом.
Ага. Гугл тоже так делает. Но только на главной странице. На проектах у них по разному.


И финал Берем самый самый дешевой хостинг и проверяем на нем ДРУПАЛ со всеми манипуляциями загрузка будет примерно средняя . 0.6 до 1.1 секунд тогда как на вордпресс будет примерно 0.3 - 0.8 секунд.
У меня есть новостной сайт с тьмой информации на главной. Блоков >10 наверно. Время генерации 0.3 сек. Что я делаю не так?
А дешевыми хостингами не надо пользоваться. Либо выбирайте нормальный, либо свой сервер VPS. Это дешево, даже у российских хостеров.

Но это мои тесты. Но еще есть одна хитрость если нужна производительность то берем фреймворк YII и все пишем что нам нужно. Там скорость будет еще выше.Так как все запросы мы сами пишем. Кешируем тоже что нам нужно
Если уж гнатся за скорость, то надо не мучится с унылым PHP, а писать на Django, как делают все культурные люди. И если нужно создавать, какой-то уникальный проект с высокими нагрузками в будущем, то это действительно лучший вариант. Для создания небольших сайтов это муторно и долго. Мне проще за один день развернуть сайт на Drupal, чем неделю дорабатывать сайты написанные с помощью Django. Человеческий квалифицированный труд слишком дорог, я лучше куплю еще один сервер за 3k$.
 
Вы ответите не подумав. Если у вас на сайте одна страница и нет кэширования, то да генерация будет быстрее если использовать один запрос. Но выигрыш будет минимален. Совсем. Если появится кэширование, то вы так и будете, уныло выполнять один этот запрос.
Не знаю не знаю, на фреймворке сталкивался с таким что просто кешировали всю страницу. И очищали кеш тогда когда в админке меняли содержимое страницы . Потом сохранялась в БД . И результат с БД полностью сохранен в Кеше. ВОТ ТУТ НАСТОЯЩАЯ скорость так как запросы в бд отсутствуют но это только для сайт визиток когда нету динамического контента.

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

Я уважаю людей которые работают с Друпалом. Но я стараюсь судить субъективно. А люди работающие с движком своим не когда не скажут что он чем то хреновый.
Друпал мощный инструмент и годится он в основном для крупных проектов, особенность каких есть активная работа и модернизация , и тут надо признать что не один движок не можно редактировать как Друпал. Не зря его называют иногда CMF ведь он что то среднее между фреймом и цмс.

Я себе голову долго ломал очень с многими людьми общался и вот к чему я дошел.


Друпал и сайт визитка - это вполне реально. Но надо признать недостатки.
1) Надо проделать не маленькую работу по оптимизации.
2) Дешевый хостинг сразу отпадает
3) Знания движка как минимум средние
4) Админка- часто заказчик просит что бы он сам мог что то менять и добавлять, и тут у Друпала в админке много чего лишнего что приводит к тому что у заказчика который не когда не работал с движками просто может потеряться особенно если у заказчика белые длинные волосы.
5) Цена - все недостатки решаются с помощью денюшек. И это иногда минус, ведь когда приходит человек и говорит мне надо сайт визитку с пару страничками и ты скажешь что это примерно n баксов в лучшем случае, а соседний организации или какой то Вася скажет что у него будет это стоит n - 50% и навешает лапшу на уши которая может звучать убедительно то тяжело конкурировать с платформой Друпал на бюджетных проектах.

Но и надо отметить плюсы
1) Модернизация - в случае если заказчик через годик скажет что я хочу интернет магазин на базе визитки, то Друпал с это задачей справится на 5
2) Скорость модернизации - готовых модулей которые в основном карказ , который чучуть переписать и полностью готов к использования для вашего проекта.

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

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

ХЗ кто читать будет но когда писал то я малеха зае...лся
 
Выбрать друпал или не выбрать - каждого субективное мнение....
На нем реально можно сделать почти все...как автор выше писал иногда его называют CMF, + его оптимизировать и чуть докодить - и такие скоростя на выходе и стабильность работы, что многие цмс курят в сторонке.... но сама цмс тяжелая, и не всем подойдет,многим нету времени и желания разбираться, некоторым дешевле заплатить и купить хороший хостинг на тормознутого зверя в виде джомблы....но потраченное время на изучение и внедрение цмс - явно не пропадет зря....
 
Не знаю не знаю, на фреймворке сталкивался с таким что просто кешировали всю страницу.
Это работает только для совсем простых страниц.

Это я наглядно пример сказал что бы понять что он прожорлив.
Это вы наглядно показали, что большинство просто не замарачивается с настройкой.

4) Админка- часто заказчик просит что бы он сам мог что то менять и добавлять, и тут у Друпала в админке много чего лишнего что приводит к тому что у заказчика который не когда не работал с движками просто может потеряться особенно если у заказчика белые длинные волосы.
В Drupal огромные возможности по темизации админки. А для добавления материалов в админку вообще лесть не надо, для этого делают форму на строну пользователя.

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

Для каких-то сервисов и нестандартных проектов я использую Python + Django. В этих случаях дополнительные сложности оправдываются.
 
Drupal неплохая весчь для автоблогинга) Порой очень неплохо выстреливает в Гугле, при знании дела конечно.. только навесить надо рекапчу с акисметом на всякий случай, и вперёд.
 
Это работает только для совсем простых страниц.

Вам надо обратить внимания на кеш так как видно что вы не работали с ним на многих уровнях. В субботу был в Киеве на конференции по yii так очень наглядно пример показали 50 тысяч данных сложных, кешируются каждый день выполняет удаление и заново создает свежий кеш Крон(Хрон). В случае отсутствия кеша Обращаемся к Sphinx и Couchbase там все оперативно обрабатывается и сразу же дает новый результат и его кишируем. Кстати этот докладчик с Компании которая консультировала Вконтакт и куча много других известных проектов. Если интересно более подробно могу скинуть ссылку на Слайды на следующий недели обещали и видео выложить.

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