Модульный подход в Drupal хорош для производительности?

Question

Предположим, мне нужно создать функции A, B и C с помощью пользовательского кодирования в Drupal с использованием хуков.

Либо я могу объединить три из них в custom1.module, либо я могу создать для них три отдельных модуля, скажемcustom1.module, custom2.module и custom3.module.

Преимущества создания трех модулей:

• Чистый код
• Удобный поиск
• Взаимнонезависимый
• Легкость фиксации в проектах с несколькими разработчиками

Минусы:

• Каждая запись модуля сохраняется в базе данных и требует запроса.

Насколько это ухудшает производительность сайта?

Лучше ли создать один большой файл пользовательского модуля для сокращения запросов к базе данных или разбить его на разные меньшие??

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

Answer 1

Я бы кодировал его исходя из того, как часто мне нужны функции A, B и C

Фактический пример:

Я создал модуль, который имел две потребности

1) Отправлять периодические электронные письма на основе предпочтений пользователяПозволяет вызвать эту функцию A 2) Пользовательский контент, созданный в модуле.Давайте назовем эту функцию B 3) Социальная интеграция.Позволяет вызывать эту функцию C

. То, что я сделал, так это то, что функция A вызывается только раз в неделю. Я сделал для нее отдельный модуль.они всегда будут вызываться вместе.

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

http://www.vmirgorod.name/10/11/5/tuning-drupal-performance

В нем приведен хороший модуль, называемый boost.Я не использовал это, но я слышал хорошие вещи об этом.

ура, Вишал

Answer 2

Файлы Drupal .module загружаются при каждой загрузке страницы.Производительность очень мала, что можно получить или потерять, просто разделив функции на разные файлы .module.Если вы не используете кэш кода операции, то вы можете повысить производительность, создав файлы .inc и ссылаясь на эти файлы в пунктах меню в hook_menu, так что эти файлы загружаются только при обращении к элементам меню.Тогда нечасто вызываемые функции не занимают место в памяти.

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

Answer 3

Меня на самом деле интересует:

Лучше ли создать один большой файл пользовательского модуля для сокращения запросов к базе данных или разбить его на несколько меньших?

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

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