7 декабря 2012 в 18:20
Уважаемые друпалеры!
Хочу услышать мнение людей, которые давно работают с Друпалом.
Я его только пытаюсь осилить, поэтому интересует ряд вопросов...
Насколько критично влияют на производительность количество модулей, сск полей и число представлений Виевс на производительность сайта, то есть на скорость загрузки страниц.
Не вредит ли то, что каждое представление и некоторые ноды темизированны руками.
Как сохранить человеческую скорость открытие страниц и обработки данных, при том что сайт довольно загружен информацией, посещаемость высокая + большое количество отдельных профилей пользователей со своими галереями и всеми прелестями.
Хочу услышать советы действительно знающих людей!
Буду очень признательна!
Комментарии
Как бэ ответы на эти вопросы есть практически в любой адекватной книге по друпалу.
ну я же конкретно спросила: поля, Виевс, темизация.
Интересно мнение людей, у которых есть подобные проекты...
В книгах помимо этого много воды...
От хостинга зависит. Если возьмете аккаунт на ИТ-Патруль у вас не будет таких вопросов.
Но если вы действительно хотите разбираться в Друпал я вам советую взять хостинг подерьмовее, тогда вы поймете "что почем". А потом ВДС, если финансы позволяют.
ну пока перешла на hvosting
но планирую и на VDS со временем...
В общем, зависит исключительно от хостинга?
от части, но, в случае с представлениями(views), учитывается сложность и правильность составления представления, одно неверно составленное представление может выдать такой SQL запрос, что сайт просто сляжет с таймаутом, сам views тут не причем. А в остальном, почти(т.е. не исключительно) все зависит от хостинга.
Да.
И да от 64 МБ ОЗУ требование Дупала. Вообще 256 МБ надо и это совсем мне дорого. Но не с украинскими фирмами.
Хвостинг - как раз тот вариант о котором я вам написал
Все таки советую еще на нескольких хостингах держать сайты, чтобы во всем разбираться.
hvosting УГ, по старому опыту говорю.
1. включайте Кэши. Как минимум, внутренние кэши друпальские должны быть включены все...
)
2. включайте кэши вьювса. У вьювса есть встроенное кэширование по времени + я ставлю еще Views Content Cacheь хотя в 6ке он не очень стабильно работал. Но на 7ке, вроде как, работает нормально. Это модуль кэширует представление до обновления материалов - например, при новом комменте вьювс обновится.
3. Встроенный вьювс есть еще и у панелей.
4. В 6ке говорили, что лучше и правильнее выводить во вьювсе не полный тизер, а поля. Как с 7кой - не знаю.
5. Темизация - не забудьте включить кэш цсс.
6. Нужно отключить ВСЕ ненужноые модули. ВСЕ неработающие модули нужно деинсталлировать + удалить физически из папки. Чем меньше модулей - тем лучше (знаю, сложно... у самой не получается
7. Элементарный совет - отключить ненужные блоки. Еще я отключаю через .info файл все неиспользуемые регионы. В 6ке как то раз переделала вообще шаблон - убрала все конструкции типа print title - записала их в шаблоне текстом. Ну знаете - там логотипы, название сайта, ссылка на главную с логотипа и т.д. и т.п. Не знаю, насколько это сильно влияет на производительноть.
8. Ставим буст.
9. Отключаем встроенный модуль Статистика, Поиск, Апдейт менеджер, все накрутки с Оверлеем.
10. Включаем встроенный модуль Троттер и настраиваем его. Он отключит модули-блоки, чтобы спасти ваш сайт если будет нечайный хабраэффект.
Пожалуй, это все, что может сделать не-Гуру друпала. Лично у меня это уже потолок - я чувствую, нужно нанимать спеца, чтобы мне тонко настроили кэширование + возможно подобрали другой хостинг и.тп. Если вы гуру, или хотите им стать, то гуглите: memcached, apc, solr, varnish и т.д.
Хостинг - берите Ит Патруль, у них изначально правильно настроенный хостинг под друпал. Как минимум, при посещаемости до 5000 человек сайты будут хорошо загружаться. Обычные хостинги (по моему опыту) откажут уже при посещаемости 1000-2000 человек...
найти мужа|любовника|друга программиста и пусть его заботят проблемы Вашего сайта;)
Зачем поиск отключать то?
Без Апдейт Менеджера лишаетесь информации об обновлении и портите статистику на друпал.орг по количеству сайтов, использующих друпал и модули
Пользуясь случаем — с какими проблемами столкнулся я.
Учту, хотя был период когда поменяла меньше чем за месяц 3 хостинга, так как по каким-то причинам хосты постоянно лежали( В общем, на хвостинге я временно) Рассмотрю ИТ-Патруль.
у него свои проблемы)
Я вообще, спасибо всем - полезно!
встроенный в друпал поиск - а) неэффективный (т.е. плохо ищет) б) грузит базу (не могу объяснить технически, то это известный факт!) Другое дело, что простой замены ему из серии - закачал модуль-врубил-забыл - нету. Нужно заменять либо Солром/Сфинксом/Яндекс/Гугл-сервер (их еще настроить нужно), либо бесплатными яндекс/гуглом.
Нужно отключать уведомления + настраивать периодичность проверок. По автомату друпал проверят модули раз в сутки + шлет письма. Нужно ставить раз в неделю, либо вообще проверять самостоятельно, т.е. не по крону.
вот это действительно плохо(
на Патруле, например, есть сфинкс(по крайней мере был).
Попробуйте модуль http://drupal.org/project/rustemmer
Мне кажется лучше узнать об обновлении (особенно связанным с безопасностью) раньше, чем позже.
Если проверять самостоятельно - то про это быстро забываешь и забиваешь на него.
Перечитайте вопрос
И перечитайте бест-практисес. Модуль апдейт может проверять обновления... эдак раз в 15 минут... для всех 200 установленных модулей...
Отключить САМ модуль - не нужно, если у вас не критическая ситуация. Но а) его нужно обязательно настроить, б) желательно еще настроить отработку крона под него, ц) его можно привязать к троттеру. Если у вашего сайта рост с 5000 посетителей до 100 000 (это мой случай), вы легко переживете пару дней без проверки обновлений.
угу. Как я и написала.
На Патруле был модуль-интергация для 6ки (скачал-включил-забыл). Но вроде как под 7ку нету.
Ребята, переехала я на Ит-Патруль! В принципе, вполне довольна!
Но, появилась проблема с изображениями на сайте.
Некоторые бэкграунды перестали отображаться. В журнале пишет, что его не найдено, при этом само изображение залито и прописано. Права на файлах 755. Сами изображения находятся в папке темы в img
Вторая проблема с теми же изображениями при загрузке(поле). Отображается кнопка загрузить, сам процес, но потом вместо картинки выдает целую петицию такого вида (кусок) -
{ "status": true, "data": "\x3cdiv id=\"edit-field-instrumenty-logo-0-ahah-wrapper\"\x3e\x3cdiv class=\"form-item\" id=\"edit-field-instrumenty-logo-0-upload-wrapper\"\x3e\n \x3clabel for=\"edit-field-instrumenty-logo-0-upload\"\x3eЛоготип магазина: \x3cspan class=\"form-required\" title=\"Обязательно для заполнения.\"\x3e*\x3c/span\x3e\x3c/label\x3e\n \x3cdiv class=\"filefield-element clear-block\"\x3e\x3cdiv class=\"widget-preview\"\x3e\x3cdiv class=\"imagefield-preview\"\x3e\x3cimg src=\"http://my_site/sites/default/files/imagefield_thumbs/images_instrymentu/2%20-%20%D0%BA%D0%BE%D0%BF%D0%B8%D1%8F.jpg?1356770867\" title=\"2 - копия.jpg\" alt=\"Уменьшенная копия изображения\" /\x3e\x3c/div\x3e\x3c/div\x3e\x3cdiv class=\"widget-edit\"\x3e\x3cinput type=\"hidden\" name=\"field_instrumenty_logo[0][UPLOAD_IDENTIFIER]\" id=\"edit-field-instrumenty-logo-0-UPLOAD-IDENTIFIER\"
Кто сталкивался, подскажите где копать...
в техподдержке, заодно и узнаете хорошая она или нет))
ps права на файлы должны быть примерно такими: 644, но скорее не в них дело
да, дело не в них. Разбираемся на пару с техподдержкой. Спасибо
- Апдейт менеджер как бы не несет нагрузки вообще, пусть себе раз в сутки проверит от этого сервер не упадет.
- Оверлей тут при чем? Я его тоже отключаю первым делом, но это связано что мне он не нравится, нагрузки он не делает.
- Поиск, это да. Встроенный в друпал малость деревянный, но нельзя его просто так отключать нужно проверить, несет ли он нагрузку, сколько страниц в базе сколько других данных для поиска, посмотреть на саму таблицу с индексами, может там и не пахнет проблемами вовсе
- Статистика, согласен, если можно заменить на аналитик, тогда отключить. Хотя нагрузка будет только при большом количестве юзеров/час.
в 7ке аналогично.
зачем тушить регионы? Зачем убирать заголовки и логотипы, это бред. Вы так экономите тысячные микросекунды, на фоне общей загрузки в 5 секунд влияния ноль целых. Кстати, это еще бессмысленно потому что вы убрали Print из шаблона, но ядро друпала об это мне знает и все равно темизирует все что вы отключили, загоняет в переменную и передает в шаблон, получается 99,9999% затрат на подготовку заголовка и логотипа все равно сервер сделал, но не вывел
Читаем еще раз http://shvetsgroup.com/ru/blog/optimization/blocks-visibility вопрос не в том что бы удалить регион, а в том что если в регионе что-то есть, но вы в шаблоне по условию этот регион не показали, то ядро выполнило 99,999% на подготовку данных и рендеринг результата, а ваш шаблон это просто проигнорировал (это как в случае убирания заголовка сайта и замена на статическое название, толку ноль а сервер гудит.
читаем еще раз мой совет
...потом обращаем внимание на слово .info
...потом понимаем, что я удалила регион не из шаблона - пейдж.тпл, а из .инфо файла = ядро друпала о нем больше не знает и не тратит ничего ни на рендеринг, ни на подготовку. Что и требовалось доказать.
Этот пункт очень важен, если вы используете пред-готовую тему. А то есть любители запихать 22 региона в тему, а то и больше. Все регионы, которые не используются, нужно обязательно отключать в .инфо файле.
Насчет лого - да, это так... баловство было
он делает нагрузку, наск. я знаю: http://drupal.org/node/1018126
«Drupal is slow Client Side because some modules use javascript and weigh heavily on your own CPU, so:
1. switch off the overlay module
2. switch off the toolbar module (which always hovers over your page at the same position, don´t know if its javascript of absolute CSS positioning, but it makes it slow) and install the administation menu module. It works better and faster.»
В любом случае. особой нагрузки смысловой оверлей не несет
так что можно и отключить 
Апдейт менеджер проверяет апдейты по крону. Если у вас крон настроен на каждые 15 минут, вот он и будет проверять каждые 15 минут... все 200 модулей... и снова через 15 минут... Так что лично я ставлю Элизия крон и настраиваю проверку обновлений раз в сутки в полночь.
идиотизм
http://drupal.org/node/1032194
просто js навешанный на тему можно профилировщиком фаербага посмотреть.
(что это такое и с чем это едят?
Я просто повторю совет Orb - читаем еще раз http://shvetsgroup.com/ru/blog/optimization/blocks-visibility
зачем? А если потом регион надо, то возвращать его назад? Какой в этом смысл и какая экономия ресурсов? нельзя так делать, да и вообще нельзя пускать людей которые не знают друпал править файлы. Вы удалили из info а в page.tpl.php остался вывод несуществующей переменной, зачем замусоривание тему, так через пару лет у вас куча неясных переменных и полный бардак в теме. Особой нагрузки регион в котором нет блоков не делает, поэтому нет смысла его трогать, пусть висит лишних 10 пустых регионов я не вижу в этом проблемы ровным счетом никакой.
Откуда такие данные? Друпал делают не полные идиоты что бы каждый крон все запускать что есть. На странице обновлений есть настройки регулярности проверки обновлений /admin/reports/updates/settings Тут как бы можно установить проверку обновлений даже раз в неделю, и как бы этой проверке все равно насколько часто запускается КРОН, хоть каждые 5 минут, а проверка обновлений пройдет раз в день.
С другой стороны кто вам сказал что проверка обновлений это тяжелый процесс для сервера? Не путайте понятия "тяжелый" и "долгий" процесс, особой нагрузки сервер не замечает с проверки обновлений, но процесс действительно может быть долгим, так как д.орг тупит или каналы заняты, но к нагрузке оно мало относится.
Не учите людей плохому, проверять обновления нужно, хоть раз в неделю но нужно.
Не всегда.
Про js - это уже оптимизация клиентской части, если уж на то пошло - нужно стараться избавляться так же и от ненужных CSS определений, кучи неиспользуемых оберток в HTML и т.д. и т.п. но быстрее будет тогда сайт на каком-нибудь фреймворке сделать(тупо меньше времени займет), а отключать десяток килобайт js из всей кучи(а куча там не маленькая) это как слону дробина.
почему?
Бывает, что один запрос работает гораздо медленнее тысячи мелких, простой пример можно увидеть нажав на кнопку "мой трекер" на этом сайте. Как-то сталкивался с этой проблемой - надо было всего лишь вывести 10 тизеров, правда по хитрому отфильтрованных и отсортированных(с использованием дополнительных таблиц), вроде бы задачка раз плюнуть, однако генерация вывода в виде полей занимала до 62 секунд(т.е. на продакшене это белый экран, да и вообще охренеть как нехорошо), а в виде тизеров доходило до 0.7 секунд, это все без кеширования(любого его вида), ах да, нод было 2,5 млн так что, стоит учитывать, что сложные запросы со временем могут замедляться(с числом сущностей), в то время как вывод в виде тизеров всегда будет работать с примерно одинаковой скоростью, хоть и делает 100500 запросов к БД, кроме того, вывод некоторых полей(пример, термины таксономии) так же создает отдельный запрос к БД для каждого поля, но, к сожалению, это работает не со всеми полями, попробуйте вывести через поля тизеры, где в этом самом тизере встречаются множественные поля(термины таксономии не в счет).
Однако, на столько тяжелые запросы на вывод именно в виде тизеров попадаются довольно редко, так что в большинстве случаев утверждение выше верно, но, к сожалению, не всегда, так-что стоит все это дело учитывать еще при разработке, кроме того, гораздо чаще попадаются "веселые" запросы, где выводить нужно именно в виде полей(к примеру тот же "мой трекер" на этом сайте), вложенные запросы зачастую могут решить эту проблему, только беда в том, что вьювс по умолчанию такие запросы не поддерживает, так что, лично я вижу всего 3 варианта:
1 альтернуть SQL запрос и перезаписать его как нужно, благо для этого во вьювс даже кнопочки в настройках имеются, на мой взгляд, это вполне быстрый и легкий способ.
2 забить на протезостроение и реализовать все через свой модуль, это проще некуда, особенно на 7рке, однако, строчек кода будет чуть больше чем во втором варианте.
3 написать хендлер-костыль для вьювс, при использовании этого способа для создания вложенного запроса это будет всем костылям костыль, и тут больше всего секса, однако при самом выводе поля можно добавить еще один легкий запрос.
Недостаток всех 3х вариантов - вносить какие либо изменения в саму вьюху через годик, или другим разработчиком, будет то еще удовольствие, а так же использование всех трех вариантов может зависеть от конкретной ситуации, в некоторых, особо тяжелых случаях, их можно смешивать.