Почему Drupal 7 так медленно? [закрыто]

Я только что создал новый сайт Drupal 7, и время загрузки слишком много. Я проверил Speed ​​Tracer у Google и вот результаты для первой страницы:

 URL http://mysite.com/
From Cache  false
Method  GET
Http Status 200
Mime-type   text/html
Total Bytes 
Request Timing  @63757 ms for 3331 ms
Response Timing @67088 ms for 379 ms
Total Timing    @63757 ms for 3710 ms

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

Есть ли у кого-то такой же опыт? Что делать, чтобы улучшить скорость?

Одна связанная с скоростью проблема была в файле конфигурации MySQL: my.cnf.

Теперь я установил следующие переменные для MySQL относительно InnoDB:

 set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2
set-variable = innodb_flush_log_at_trx_commit=0

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

Я думаю, что проблема с тайм-аутом для InnoDB может быть проблемой. Каково ваше мнение?

Теперь у меня есть невероятное время ожидания здесь: 10760 мс на http://localhost/mysite/user:

 URL http://localhost/mysite/user
From Cache  false
Method  GET
Http Status 200
Mime-type   text/html
Total Bytes 
Request Timing  @12090ms for 10471ms
Response Timing @22561ms for 288ms
Total Timing    @12090ms for 10760ms

Есть некоторые странные вещи, потому что проблема заключается не в Response Time Drupal, который 288 мс (разумно, я думаю), но Request Time, 10471 мс

Почему время Request Time так долго? И что это заставляет?

Вот мои настройки и модули:

APC установлен /включен и Cache pages for anonymous users, Cache blocks, Compress cached pages, Aggregate and compress CSS files, Aggregate JavaScript files включены все

У меня установлены следующие модули:

  • blockify
  • CTools
  • google_analytics
  • i18n
  • languageicons
  • metatags_quick
  • nice_menus
  • omega_tools
  • page_title
  • Pathauto
  • site_map
  • токен
  • переменная
  • вид
  • Webform
  • WYSIWYG
  • xmlsitemap
134 голоса | спросил Ek Kosmos 13 MarpmSun, 13 Mar 2011 19:33:58 +03002011-03-13T19:33:58+03:0007 2011, 19:33:58

16 ответов


70

В настоящее время на некоторых серверах /серверах Drupal 7 возникают проблемы с производительностью.

В качестве начала вы можете попробовать моментальный снимок 7.x-dev, чтобы узнать, есть ли какие-либо улучшения.

Этот общий хостинг, собственный сервер, локальная среда разработки?

Вы уже использовали Drupal 6 в той же среде?

Включили ли вы основные параметры производительности, например, агрегацию css /js?

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

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

ответил Berdir 13 MarpmSun, 13 Mar 2011 21:17:12 +03002011-03-13T21:17:12+03:0009 2011, 21:17:12
88

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

SELECT name, filename FROM system WHERE type = 'module' AND status = 1 ORDER BY filename

И очистите все модули, которые все еще включены, но отсутствуют в файловой системе.

В целом Drupal 7 является более ресурсоемким и масштабируемым, чем Drupal 6, за исключением некоторых неудачных регрессий, подобных этому.

ответил Damien Tournoud 17 MaramThu, 17 Mar 2011 05:08:29 +03002011-03-17T05:08:29+03:0005 2011, 05:08:29
21

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

  

факт заключается в том, что drupal 7 очень полезен в моем опыте

Я использовал drupal 7 на vps с memcache, Apc установлен, и он летал как что угодно.

Drupal 7 оптимизирован из коробки для большого сайта с расширенными функциями кеширования, обратным прокси-сервером, балансировщиком нагрузки. Вы сказали бы, что это заставит drupal 6 тоже летать, но есть заметная разница между drupal 6 и drupal 7 performace с тем же самым высоким уровнем настройки сервера.

Из satring я использовал drupal с RAM объемом более 64 МБ и, следовательно, у меня не было большой проблемы с drupal.

Drupal 7 может сначала вас отпустить, но с учетом надлежащей аппаратной и программной среды вы можете делать чудеса с drupal с точки зрения скорости.

ответил Nikhil 13 MarpmSun, 13 Mar 2011 22:13:11 +03002011-03-13T22:13:11+03:0010 2011, 22:13:11
17

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

Мой первый шаг, когда обновление производительности - проверка базы данных. Включите MySQL медленное ведение журнала запросов и обычное ведение журнала (не на производстве !!) и запустите некоторый паук над сайтом (или щелкните через 20 страниц или около того). Сделайте это как для аутентифицированного, так и для анонимного пользователя.

Затем вы можете исследовать журналы. Иногда просто заглядывать в журналы уже много проблем; например, 2000+ запросов для создания главной страницы (немыслимо!). Или медленный запрос нажимается снова и снова.

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

Затем проследите, какой модуль запускает запросы. Если вы можете привести определенный проблемный (набор) запросов /запросов обратно к одному модулю, подумайте об отключении этого модуля или перезаписи.

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

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

ответил berkes 30 MarpmWed, 30 Mar 2011 14:14:26 +04002011-03-30T14:14:26+04:0002 2011, 14:14:26
14

Я замечаю ту же проблему со всеми установками Drupal 7: если ваш запрос иногда занимает так много времени, это потому, что задачи cron .

В Drupal 7 cron привязан к посещению пользователя; поэтому, если ваш cron настроен на огонь каждые 1 или 3 часа, вы получите длинное время запроса. Cron wil проверяет наличие новых модулей, переиндексирует вашу БД и т. Д.

Вам просто нужно настроить вызов cron извне и отключить ваш cron.

ответил spiderneo 27 Jpm1000000pmFri, 27 Jan 2012 12:46:00 +040012 2012, 12:46:00
13

Drupal 7 использует слишком много файлов. И, как и D6, он использует слишком много SQL-запросов (по сравнению с другими CMS). Таким образом, первый хит может занять много времени, особенно если у вас медленный диск, а файлы не находятся в кэше ОС.

В обычной ситуации, когда доступен кеш, все должно быть в порядке. Существует много уровней кеша: кеш OS, чтобы избежать чтения файлов PHP, кеш-код операции (например, APC, не включен по умолчанию), чтобы избежать повторного анализа файлов PHP, кеш MySQL, чтобы избежать повторного выполнения запросов несколько раз.

ответил jcisio 17 MarpmThu, 17 Mar 2011 21:17:23 +03002011-03-17T21:17:23+03:0009 2011, 21:17:23
8

По моему опыту, хостинг-провайдер является ключом к Drupal. Я бы сделал некоторые из настроек, перечисленных выше, но только слегка увеличил производительность. Boost (и Boost Expire) помогли больше всего, но все еще имели проблемы с производительностью на стороне администратора, даже сбой.

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

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

Это не сообщение против GoDaddy или pro-HostGator ... Я просто подчеркиваю тот факт, что я получил замечательное увеличение производительности, просто изменив свою конкретную среду хостинга.

ответил Tom Storey 8 PMpSun, 08 Apr 2012 17:41:35 +040041Sunday 2012, 17:41:35
6

Выход из администрирования и проверка всех администраторов были устранены, устранены проблемы с ответами для анонимных пользователей. Я использую несколько базовых модулей и коммерческую торговлю drupal. Сайт на самом деле не такой большой, и это всего 2 администратора. Но заметив, что администратор отмечен вошедшим в систему, сайт не отвечает в течение примерно 5-10 секунд для всех и везде. Записан Может или может не помочь всем, но для некоторых людей могут решить некоторые головные боли. Я хотел бы знать, почему, хотя, если кто-то еще знает. Я полагаю, что я администратор, у меня должно быть что-то включенное при регистрации в том, что он выполняет какое-то повторное кэширование, обработку или что-то, о чем я не знаю. Это мои 2 цента, надеюсь, что это кому-то поможет.

ответил Matt 24 AM000000120000004131 2012, 00:41:41
4

Я нашел этот пост, и он может быть вам полезен.

  

Не должно иметь негативного влияния на производительность для Drupal или любого другого веб-приложения при условии, что PHP 5.3 настроен правильно.

     

Если вы сделали какую-либо конфигурацию php.ini при использовании PHP 5.2, обязательно прочитайте предостерегающее примечание в разделе поддержки PHP 5.3 поддержки GatorJacob «sticky» на этом же форуме. Неспособность очистить любые такие пересадки «EasyConfig» до замены версии, скорее всего, будет использовать неправильные пути и другие параметры, которые могли бы существенно повлиять на конечные результаты.

ответил Andrew Smith 27 Jpm1000000pmFri, 27 Jan 2012 14:13:37 +040012 2012, 14:13:37
4

У меня была эта проблема (от 10 секунд до первого байта) на рабочем сервере, когда разработчик установил имя домена в качестве сервера базы данных, а не имя хоста сервера базы данных в settings.php ...

Остерегайтесь!

ответил Pan Chrono 1 MarpmFri, 01 Mar 2013 13:19:11 +04002013-03-01T13:19:11+04:0001 2013, 13:19:11
4

Если вы не можете установить Лак , Альтернативный кэш PHP (APC) , Memcache или других модулей, требующих программного обеспечения на стороне сервера, я советую вам установить Агрегатный кэш , Кэш объектов и amp; кэш файлов .

Эти модули не требуют установки какого-либо программного обеспечения на стороне сервера, и они работают довольно хорошо, улучшая производительность встроенной системы кеша. Я тестировал их на производственной площадке с Drupal 7, и они достаточно стабильны.

Примечание. Расширенное агрегирование CSS /JS должно дать вам лучшие результаты, но оно вводит много ошибок, потому что он еще не был правильно перенесен на Drupal 7. Я никогда не пробовал Boost или Альтернативный кэш базы данных (ADBC) , если честно.

ответил warmth 14 J0000006Europe/Moscow 2013, 01:52:19
3

Если вы находитесь на сервере Dedicated /VPS, установите ваш обработчик PHP в FastCGI (fcgi) или аналогичный.

Многие серверы по умолчанию устанавливают обработчик PHP на SuPHP. SuPHP работает медленно, не работает с memcached и часто приводит ваш сайт к трафику. Разница огромна; Я усвоил это с трудом.

ответил timofey 26 AMpFri, 26 Apr 2013 02:45:17 +040045Friday 2013, 02:45:17
3

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

В зависимости от профиля трафика я рекомендую использовать Лак перед Drupal. Для анонимных пользователей (то есть без регистрации) это будет работать с кэшированными страницами быстро, обычно <200 мс. Записанные пользователи должны обходить лак, но, взяв значительную нагрузку с Apache /PHP /Drupal /MySQL, вы также увидите улучшения здесь.

ответил edkay 30 Maypm13 2013, 14:25:27
2

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

Кроме того, он не говорит, что у вас есть глобальное перенаправление, но (в случае, если вы это делаете) я обнаружил, что он не играет хорошо с i18n.

ответил user1750 31 J000000Sunday11 2011, 21:01:31
-1

Я новичок в Drupal, как через месяц.

Недавно у меня были очень серьезные проблемы с Drupal 7, когда страницы занимали около 5-7 минут.

От стороны администратора он будет висеть на 20 минут. Я попробовал очистить кэш, но не смог и получил сообщение «Плохой шлюз».

Затем я попытался восстановить таблицы, но случайно выбрал «удалить» и потерял всю лот - мне повезло, что я сделал резервную копию перед раздачей.

Для тех, кто не знает Drupal, некоторые из найденных нами решений могут быть довольно сложными или PhpAdmin, если на то пошло.

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

Теперь страницы загружаются как на передний, так и на задний план в течение 1-3 секунд.

Обратите внимание: я на общем сервере (MediaTemple), поэтому это может не работать для людей на выделенном хостинге.

  1. резервное копирование базы данных
  2. откройте файл .sql в TextEdit /Espresso /equivilant
  3. найти и заменить «INNODB» на «MyISAM»
  4. сохранить
  5. вернуться к PhpAdmin кликнуть по базе данных
  6. dump /empty /delete tables (не уверен, что это правильно)
  7. Загрузите файл .sql, который вы изменили.

Весь процесс занимает не более 3 минут.

Я нашел решение здесь:

http://anthonymclin.com/fixing-hangs-drupal- админа медиа-храмовый-хостинг

Надеюсь, это поможет кому-то еще.

ответил 15 FebruaryEurope/MoscowbFri, 15 Feb 2013 19:49:03 +0400000000pmFri, 15 Feb 2013 19:49:03 +040013 2013, 19:49:03
-10

Друпал - голодный зверь. Большинство веб-серверов не настроены на то, чтобы предоставить PHP необходимое количество оперативной памяти. Перейдите в php.ini, увеличьте объем памяти до 64M и посмотрите, как это происходит.

ответил Codeblind 13 MarpmSun, 13 Mar 2011 19:36:23 +03002011-03-13T19:36:23+03:0007 2011, 19:36:23

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132