19 простых методов ускорить сайт на Друпале [уровень: продвинутый новичок]

Аватар пользователя ttenz ttenz 4 октября 2015 в 8:53
6

Данная информация - вытяжка для продвинутых новичков. Чеклист для более продвинутых составляет около 60 пунктов.

Скорость сайта это один из его самых важных параметров. Если сайт будет загружаться долго, то посетитель просто уйдет c сайта, не дождавшись загрузки. Гугл так же стал обращать внимание на скорость загрузки сайта и понижает позиции сайта, если он медленный.  

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

Есть два классных инструмента для проверки скорости сайта - YSlow и GTmetrix,  их нужно использовать после каждого внесения изменения. Записывай ключевые параметры измерений (загрузку страницы, размер страницы, число HTTP запросов и общую оценку в баллах) перед каждым внесением изменений, чтобы быть уверенным, что ты двигаешься в правильном направлении. Также можно попробывать JMeter и Apache Bench.


Читать далее...

Комментарии

Аватар пользователя Evgeny S Evgeny S 4 октября 2015 в 10:02
"ttenz" wrote:

Выключи Update Manager

Update Manager обращается к Drupal.org, чтобы проверить нуждаются ли модули на сайте в обновлении. Проверяя, он добавляет нагрузку на сайт.

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

Это из серии "вредные советы".
Остальное большинство тоже масло масляное маслом - можно было бы заменить одни пунктом "все кешировать". Хотя кому-то может и пригодится.

Аватар пользователя ttenz ttenz 4 октября 2015 в 12:31
"Garin33" wrote:

Хотя кому-то может и пригодится.

мне лично очень пригодилось, я увидел много ньюансов для новичков.

"Garin33" wrote:

одни пунктом "все кешировать"

это да, но здесь как.

Аватар пользователя ttenz ttenz 4 октября 2015 в 13:22
"kosHta" wrote:

это как то сказывается на рейтинге у поисковиков? В смысле переиндексация, падение уровня и прочее

так поисковик по-любому видит его как, переиндексации не требуется: http://www.evolvedwebsites.com.au/googlebot/

по позициям, сео - подымает, т.к. сейчас к скорости внимание гугла.

Аватар пользователя vbard vbard 4 октября 2015 в 17:08

ttenz, спасибо! я в закладки добавил, просто даже как чеклист. Вся инфа в одном месте.

Аватар пользователя ttenz ttenz 4 октября 2015 в 17:12
"sumerian" wrote:

не за что. я очень рад, тем более инфа очень полезная, если читать внимательно, п.ч. после этого уже можно делать настройку на серверной части (redis, memcache и т.п.).

Аватар пользователя dashiwa dashiwa 4 октября 2015 в 17:31

Может стоит запихать это все в одну фичу? Чтоб нажал на кнопку и все заработало..

Аватар пользователя ttenz ttenz 4 октября 2015 в 17:39
"dashiwa" wrote:

стоит запихать это все в одну фичу

"ttenz" wrote:

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

Аватар пользователя ttenz ttenz 4 октября 2015 в 19:37
"kosHta" wrote:

на слабом клиентском сервере реакцию

так это и рассчитано на слабый сервер.

Аватар пользователя dashiwa dashiwa 4 октября 2015 в 20:51

Вижу несколько модулей, которые могли бы включить в ядро..
Fast 404
Advanced CSS/JS Aggregation
Boost
Entity Cache

Аватар пользователя drupby drupby 4 октября 2015 в 21:31
"ttenz" wrote:

Entity Cache  кеширует всю сущность в таблице кэширования (cache table). Каждая загружаемая сущность становится просто одной строчкой в таблице кэширования базы.

Я бы еще добавил Display Cache http://drup.by/articles/entity-cache-i-display-sache-kompleksnoe-keshiro...

Аватар пользователя Orion76 Orion76 5 октября 2015 в 6:23

Вы что-то имеете против кэша?-)
Если на более 1000(цыфра с потолка) показов материала его контент меняется тольео 1!! раз, то здравый смысл просто истерит:
нахрена эти сотни запросов к БД, сотни хуков и километры остального кода для генерации вывода на каждый пук запрос страницы, когда достаточно одного!! cache_get (1 запрос к БД к одной таблице по индексу)!!???

Меняем цыфру с потолка и считаем, какая экономия ресурсов сервера.

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

Аватар пользователя marazmus marazmus 5 октября 2015 в 7:50

У меня был случай, когда включенный кеш блоков добавлял нехилых тормозов. Правда это был сложняк с Solr + Search API, причем разобрался я в проблеме не сам, отличные ребята помогли. Так что не всегда кэш это панацея :)

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

Аватар пользователя ttenz ttenz 5 октября 2015 в 7:55
"marazmus" wrote:

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

+ эту статью нужно читать очень очень внимательно, много нюансов:

"ttenz" wrote:

«Есть два классных инструмента для проверки скорости сайта - YSlow и GTmetrix, их нужно использовать после каждого внесения изменения. Записывай ключевые параметры измерений (загрузку страницы, размер страницы, число HTTP запросов и общую оценку в баллах) перед каждым внесением изменений, чтобы быть уверенным, что ты двигаешься в правильном направлении. Также можно попробывать JMeter и Apache Bench.»

Аватар пользователя mozh mozh 5 октября 2015 в 11:19
"Garin33" wrote:

Views Content Cache решает эту проблему. Он проверяет изменился ли контент и, если контент изменился, то кэш обновляется.

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

Аватар пользователя ttenz ttenz 5 октября 2015 в 11:37
"mozh" wrote:

моудль не обновляет кеш

сожалею, что Вы получили отрицательный опыт с этим модулем, попробуйте внимательно изучить его настройки.

+ почитайте https://www.drupal.org/node/871274

NB! «You only really need to set a minimum lifetime if your cache segments are being updated very regularly, say on a busy site where a new blog post is added every five seconds. A maximum lifetime will be useful if your view contains time sensitive data, like: 'Posted 3 hours ago' or to ensure that the data is correct, views content cache isn't perfect and the maximum lifetime allows you to ensure that at least once a day, for example, the cache is 'flushed'.»

+ посмотрите https://vimeo.com/93549149

Аватар пользователя mozh mozh 5 октября 2015 в 13:05
"ttenz" wrote:

You only really need to set a minimum lifetime

Спасибо, попробуем поставить минуту вместо none,хотя интуитивно это непонятно

Аватар пользователя dashiwa dashiwa 6 октября 2015 в 0:21

Производительность как и безопасность сайтов очень обьемная и сложная тема..
Для примера посмотрите и зацените такую книжку
http://chimera.labs.oreilly.com/books/1230000000545/index.html
Это общие сведения.
Есть, кстати по друпалу хорошая..

Аватар пользователя vbard vbard 6 октября 2015 в 2:36
"kosHta" wrote:

ориентированы на программеров?

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

Аватар пользователя gor gor 7 октября 2015 в 2:41

ttenz, рекомендую добавить пункт установки и настройки
D7 https://www.drupal.org/project/filecache
D6 https://www.drupal.org/project/cacherouter
С обязательным хранением views кеша на диске.

На примере DH Elastic, это существенно снижает нагрузку на MySQL Bandwidth и если IO на хостинге не забито, будет прирост в производительности и вес базы меньше.

Аватар пользователя bsyomov bsyomov 22 марта 2017 в 19:10

Вся проблема в том, что это может работать как лучше, так и хуже кеша в базе. И чтобы выбрать решение надо довольно хорошо разобраться как, и когда применять, Или проводить масштабное тестирование обои вариантов снимая показания довольно долгое время - io может садиться в определённые часы и.т.п.
Т.е. это ну совсем не на новичков, даже продвинутых на самом-то деле.

Аватар пользователя ttenz ttenz 7 октября 2015 в 4:43
"kosHta" wrote:

Может быть есть ещё какое то условие?

т.к. владелец vps это уже не новичок, то

под nginx, он по другому настраивается http://www.drupal.ru/node/103671

+ https://github.com/perusio/drupal-with-nginx/blob/D7/apps/drupal/drupal_...

+ чисто моё имхо на собственном vps на nginx, большого смысла нет, на нём можно использовать более эффективные серверные методики (мне нравится redis), но для шаред boost - однозначно, да.

Аватар пользователя deb deb 12 октября 2015 в 17:40
"gor" wrote:

С обязательным хранением views кеша на диске.

Очень странный модуль. Чем файловое хранение лучше мускла? Выборка по первичному ключу в мускле работает очень быстро. Короче польза от такого модуля крайне сомнительна.

Аватар пользователя gor gor 12 октября 2015 в 19:03
"deb" wrote:

Очень странный модуль. Чем файловое хранение лучше мускла? Выборка по первичному ключу в мускле работает очень быстро. Короче польза от такого модуля крайне сомнительна.

у MySQL возникают проблемы производительности после 20МБ/сек трафика (in out из базы данных)
VIEWS - генерирует этот трафик. И чем больше у вас представлений и данных тем больше трафика.
По сути получается что большая часть времени тратится на получения этих данных из базы нежели на их выборку.
В итоге при переносе на файловый кеш, нагрузка уходит на IO дисковой системы, которая лучше рассчитана на такие нагрузки.
По сути разница получается между "IO по сети + IO по файлу базы данныхх" и "IO по диску". Это позволяет сохранить производительность базы данных для целевого использования, вместо хранения кеша.

Альтернативно можно хранить кеш в memcached но его установка на большей части хостингов не доступна или требует определенных знаний от пользователя.
Опять же memcached использует память для хранения кеша. Она более дорогая чем дисковое пространство.
Тут уже надо смотреть на конкретный проект.

В то время как использование filecache (cacherouter) дает мгновенный результат.
На примере DH.Elastic стоимость хостинга падает в разы для клиента.

Аватар пользователя bsyomov bsyomov 22 марта 2017 в 19:31

«у MySQL возникают проблемы производительности после 20МБ/сек трафика (in out из базы данных)»
Это просто не так. Это зависит от сети, железа, настроек и.т.п. Т.е. эта фраза, в реальности, отражает один конкретный кейс, и не связана с Mysql вообще. Нет у него такого архитектурного ограничения. В вашем конкретном случае это так работает не более того.

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

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

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

Резюме по этому поводу: Да, иногда, файловый кеш лучше. В реальности, это не так и часто. Дисковый IO на большинстве хостингов является бутылочным горлышком, особенно, на не дорогих VPS.

Аватар пользователя Диана Диана 14 октября 2015 в 10:43
"ttenz" wrote:

Кэширование представлений очень классная штука

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

Аватар пользователя ttenz ttenz 14 октября 2015 в 11:42
"Диана" wrote:

Views Infinite Scroll

для начала бы попробовал time-based кэширование вьюз, без доп модулей.

+ исчезают ли, если заменить на лайт пейджер?
+ я бы ещё попробывал Loads More (Views infinite scroll использует свой собственный аякс запрос)

Аватар пользователя Диана Диана 14 октября 2015 в 11:57
"ttenz" wrote:

исчезают ли, если заменить на лайт пейджер?

неа) даже без кеширования

вопрос, риторический. Но в чем вообще прелесть CMS-сок, если модулями не пользоваться? )))

Аватар пользователя ttenz ttenz 14 октября 2015 в 11:56
"Диана" wrote:

вообще, вопрос, наверное, риторический

понятно, т.е. проблема в Views infinite scroll, попробуйте найти ему альтернативу или немного его подстроить (число выводимых итемс и т.п.)

Аватар пользователя ttenz ttenz 14 октября 2015 в 12:00
"Диана" wrote:

Поэкспериментирую. Спасибо!

пока не за что. ajax во вьюхе не включен?

Аватар пользователя Диана Диана 14 октября 2015 в 12:49

Спасибо за рекомендацию! Попробую.

Вообще тема очень ценная в свете дня.)))

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

Аватар пользователя vbard vbard 30 октября 2015 в 0:37
"ttenz" wrote:

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

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

Аватар пользователя ttenz ttenz 30 октября 2015 в 4:32
"sumerian" wrote:

выбираю во вьюхе просто "Кеширование

это и имелось ввиду, т.е. у них собственное некоровское кеширование.

Аватар пользователя artemmian artemmian 6 марта 2016 в 12:18

Прошелся, как по чек-листу и поставил почти все. Посмотрим, что из этого получится)