Почему 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
16 ответов
В настоящее время на некоторых серверах /серверах Drupal 7 возникают проблемы с производительностью.
В качестве начала вы можете попробовать моментальный снимок 7.x-dev, чтобы узнать, есть ли какие-либо улучшения.
Этот общий хостинг, собственный сервер, локальная среда разработки?
Вы уже использовали Drupal 6 в той же среде?
Включили ли вы основные параметры производительности, например, агрегацию css /js?
Чтобы сделать что-нибудь еще, вам действительно нужно выяснить, что именно происходит медленно, часто возникает узкое место, которое замедляет работу всего сайта. Для начала вы можете включить devel.module и журнал запросов, чтобы узнать, есть ли на этой странице медленные запросы.
Если это ваш собственный сервер, я настоятельно рекомендую установить и включить APC.
Скорее всего, вы нажимаете Избегайте повторного сканирования каталога модулей, когда отсутствуют несколько модулей . Это случается, если у вас есть недостающие модули в вашей установке. Попробуйте проверить системную таблицу:
SELECT name, filename FROM system WHERE type = 'module' AND status = 1 ORDER BY filename
И очистите все модули, которые все еще включены, но отсутствуют в файловой системе.
В целом Drupal 7 является более ресурсоемким и масштабируемым, чем Drupal 6, за исключением некоторых неудачных регрессий, подобных этому.
Это не 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 с точки зрения скорости.
i18n является сложным модулем из-за его взаимодействия почти с каждым запросом, переданным в базу данных. Это может быть проблемой в вашем случае. Но это может быть не проблема. Некоторые другие модули могут быть проблематичными.
Мой первый шаг, когда обновление производительности - проверка базы данных. Включите MySQL медленное ведение журнала запросов и обычное ведение журнала (не на производстве !!) и запустите некоторый паук над сайтом (или щелкните через 20 страниц или около того). Сделайте это как для аутентифицированного, так и для анонимного пользователя.
Затем вы можете исследовать журналы. Иногда просто заглядывать в журналы уже много проблем; например, 2000+ запросов для создания главной страницы (немыслимо!). Или медленный запрос нажимается снова и снова.
Следующий шаг - использовать инструмент, такой как MySQLsla , чтобы создать несколько отчетов о том, что происходит в базе данных.
Затем проследите, какой модуль запускает запросы. Если вы можете привести определенный проблемный (набор) запросов /запросов обратно к одному модулю, подумайте об отключении этого модуля или перезаписи.
Если это вам не помогло, исследуйте, взаимодействует ли какой-либо модуль с запросами или изменяет какое-то важное поведение. например i18n, как известно, взаимодействует с запросами, превращая в противном случае довольно тощие запросы в медленные запросы. Органические группы также являются одним из таких модулей.
Только когда вы видите, что в базе данных нет проблем, продолжайте поиск проблем с производительностью в остальном коде Drupals.
Я замечаю ту же проблему со всеми установками Drupal 7: если ваш запрос иногда занимает так много времени, это потому, что задачи cron .
В Drupal 7 cron привязан к посещению пользователя; поэтому, если ваш cron настроен на огонь каждые 1 или 3 часа, вы получите длинное время запроса. Cron wil проверяет наличие новых модулей, переиндексирует вашу БД и т. Д.
Вам просто нужно настроить вызов cron извне и отключить ваш cron.
Drupal 7 использует слишком много файлов. И, как и D6, он использует слишком много SQL-запросов (по сравнению с другими CMS). Таким образом, первый хит может занять много времени, особенно если у вас медленный диск, а файлы не находятся в кэше ОС.
В обычной ситуации, когда доступен кеш, все должно быть в порядке. Существует много уровней кеша: кеш OS, чтобы избежать чтения файлов PHP, кеш-код операции (например, APC, не включен по умолчанию), чтобы избежать повторного анализа файлов PHP, кеш MySQL, чтобы избежать повторного выполнения запросов несколько раз.
По моему опыту, хостинг-провайдер является ключом к Drupal. Я бы сделал некоторые из настроек, перечисленных выше, но только слегка увеличил производительность. Boost (и Boost Expire) помогли больше всего, но все еще имели проблемы с производительностью на стороне администратора, даже сбой.
Я переключил свой хостинг с GoDaddy на HostGator, и все работает так быстро! Я был очень доволен сервисом GoDaddy и не хотел менять хостинг, но это был действительно ключ! Я совершенно не разбираюсь в аппаратных средствах /памяти и т. Д., Поэтому я не могу сказать вам, какая конкретная спецификация лучше, но она работает для меня!
Я обслуживаю несколько клиентов и теперь отказываюсь размещать в другом месте. Сайт просто не будет работать должным образом, и я не хочу делать миллион хитростей, чтобы получить что-то едва приемлемое!
Это не сообщение против GoDaddy или pro-HostGator ... Я просто подчеркиваю тот факт, что я получил замечательное увеличение производительности, просто изменив свою конкретную среду хостинга.
Выход из администрирования и проверка всех администраторов были устранены, устранены проблемы с ответами для анонимных пользователей. Я использую несколько базовых модулей и коммерческую торговлю drupal. Сайт на самом деле не такой большой, и это всего 2 администратора. Но заметив, что администратор отмечен вошедшим в систему, сайт не отвечает в течение примерно 5-10 секунд для всех и везде. Записан Может или может не помочь всем, но для некоторых людей могут решить некоторые головные боли. Я хотел бы знать, почему, хотя, если кто-то еще знает. Я полагаю, что я администратор, у меня должно быть что-то включенное при регистрации в том, что он выполняет какое-то повторное кэширование, обработку или что-то, о чем я не знаю. Это мои 2 цента, надеюсь, что это кому-то поможет.
Я нашел этот пост, и он может быть вам полезен.
Не должно иметь негативного влияния на производительность для Drupal или любого другого веб-приложения при условии, что PHP 5.3 настроен правильно.
Если вы сделали какую-либо конфигурацию php.ini при использовании PHP 5.2, обязательно прочитайте предостерегающее примечание в разделе поддержки PHP 5.3 поддержки GatorJacob «sticky» на этом же форуме. Неспособность очистить любые такие пересадки «EasyConfig» до замены версии, скорее всего, будет использовать неправильные пути и другие параметры, которые могли бы существенно повлиять на конечные результаты.
У меня была эта проблема (от 10 секунд до первого байта) на рабочем сервере, когда разработчик установил имя домена в качестве сервера базы данных, а не имя хоста сервера базы данных в settings.php ...
Остерегайтесь!
Если вы не можете установить Лак , Альтернативный кэш PHP (APC) , Memcache или других модулей, требующих программного обеспечения на стороне сервера, я советую вам установить Агрегатный кэш , Кэш объектов и amp; кэш файлов .
Эти модули не требуют установки какого-либо программного обеспечения на стороне сервера, и они работают довольно хорошо, улучшая производительность встроенной системы кеша. Я тестировал их на производственной площадке с Drupal 7, и они достаточно стабильны.
Примечание. Расширенное агрегирование CSS /JS должно дать вам лучшие результаты, но оно вводит много ошибок, потому что он еще не был правильно перенесен на Drupal 7. Я никогда не пробовал Boost или Альтернативный кэш базы данных (ADBC) , если честно.
Если вы находитесь на сервере Dedicated /VPS, установите ваш обработчик PHP в FastCGI (fcgi) или аналогичный.
Многие серверы по умолчанию устанавливают обработчик PHP на SuPHP. SuPHP работает медленно, не работает с memcached и часто приводит ваш сайт к трафику. Разница огромна; Я усвоил это с трудом.
Как уже упоминалось, как только вы вышли за рамки тривиального сайта, Drupal довольно ресурсоемкий. В частности, даже с кэшем Drupal и такими инструментами, как APC, каждый запрос по-прежнему включает в себя множество запросов к базе данных.
В зависимости от профиля трафика я рекомендую использовать Лак перед Drupal. Для анонимных пользователей (то есть без регистрации) это будет работать с кэшированными страницами быстро, обычно <200 мс. Записанные пользователи должны обходить лак, но, взяв значительную нагрузку с Apache /PHP /Drupal /MySQL, вы также увидите улучшения здесь.
Я испытал это на днях с сайта. Оказывается, моим хостом был процессор, дросселирующий сайт.
Кроме того, он не говорит, что у вас есть глобальное перенаправление, но (в случае, если вы это делаете) я обнаружил, что он не играет хорошо с i18n.
Я новичок в Drupal, как через месяц.
Недавно у меня были очень серьезные проблемы с Drupal 7, когда страницы занимали около 5-7 минут.
От стороны администратора он будет висеть на 20 минут. Я попробовал очистить кэш, но не смог и получил сообщение «Плохой шлюз».
Затем я попытался восстановить таблицы, но случайно выбрал «удалить» и потерял всю лот - мне повезло, что я сделал резервную копию перед раздачей.
Для тех, кто не знает Drupal, некоторые из найденных нами решений могут быть довольно сложными или PhpAdmin, если на то пошло.
Я нашел более простой и менее сложный способ - не уверен, что это правильный путь, но я обнаружил, что зависающие проблемы и медлительность полностью исчезли. Если у вас есть резервная копия, вы всегда можете вернуться.
Теперь страницы загружаются как на передний, так и на задний план в течение 1-3 секунд.
Обратите внимание: я на общем сервере (MediaTemple), поэтому это может не работать для людей на выделенном хостинге.
- резервное копирование базы данных
- откройте файл .sql в TextEdit /Espresso /equivilant
- найти и заменить «INNODB» на «MyISAM»
- сохранить
- вернуться к PhpAdmin кликнуть по базе данных
- dump /empty /delete tables (не уверен, что это правильно)
- Загрузите файл .sql, который вы изменили.
Весь процесс занимает не более 3 минут.
Я нашел решение здесь:
http://anthonymclin.com/fixing-hangs-drupal- админа медиа-храмовый-хостинг
Надеюсь, это поможет кому-то еще.
Друпал - голодный зверь. Большинство веб-серверов не настроены на то, чтобы предоставить PHP необходимое количество оперативной памяти. Перейдите в php.ini, увеличьте объем памяти до 64M и посмотрите, как это происходит.