Комментарии 19
А при чем тут Drupal? Судя по заголовку, тут должна была быть оптимизация друпала, а не LAMP'а. По крайней мере мне так показалось.
Заголовок был «Оптимизация сервера под Drupal».
Да, но в статье описана довольно стандартная оптимизация LAMP'а с замерами. Причем оптимизация заключалась в изменении ровно двух настроек для PHP и чуть большего их количества для MySQL.
У каждой информации есть своя целевая аудитория. Моя рассчитана на тех, кто берёт готовый сервер и не ковыряется в его потрохах. И не догадывается, что парой простых действий можно что-то достаточно ощутимо изменить. А замеры я вообще нигде не встречал. Если Вы можете поделиться ещё какими-либо тонкостями оптимизации LAMP, которые были бы универсальны, а не проекто-зависимы, с удовольствием дополню ими статью.
Пожалуйста
Вообще, я не придирался к содержанию (а стоило бы). Думаю, многие поддержает, если предложу убрать друпал из заголовка. Вводит в заблуждение же. Друпал здесь просто для примера.
Вообще, я не придирался к содержанию (а стоило бы). Думаю, многие поддержает, если предложу убрать друпал из заголовка. Вводит в заблуждение же. Друпал здесь просто для примера.
Проще говоря, увеличение лимита памяти, установка APC, включение кеша MySQL это не оптимизация. Это такой базис, что и описывать не стоит.
По статье — реклама ВПС и сервера, ничего более.
По статье — реклама ВПС и сервера, ничего более.
я вообще не вижу смысла в данной статье. Тут и сервер не оптимизируется, ни Друпал.
Полностью поддерживаю Akuma — Друпалом тут и не пахнет, с таким же успехом можно переименовать статью в оптимизацию Джумлы/вордпресса и в начальных абзацах заменить базовую CMS на другую.
Танцы вокруг memory_limit вообще вгоняют в ступор:
> А вот 128M порой оказывается маловато. Впрочем, это нельзя назвать оптимизацией, это скорее жизненная необходимость.
Вы хоть с Друпалом сталкивались, хоть раз до написания статьи? Друпалу хватит 32-64Мб если сайт настроен и запущен. 64-128Мб если на сайте делают контент с image style, больше 128Мб это если там уже что-то намутили разработчики или сайт специфичен, 256Мб это с запасом для 99% друпал сайтов.
Но в любом случае данный показатель к нагрузке не относится, РНР либо отработает, либо выдаст ошибку, каким образом у вас стало работать быстрее для меня загадка и я с удовольствием почитаю как влияет memory_limit на нагрузку сервера или повышения быстродействия, или почему пиковое потребление РНР сократилось?! Выходит что когда мало памяти было, то у вас часть страниц тупо падало на начале обработки?
Настройка MySQL как-то у вас «по-ламерски» что ли. Тут есть тонна ньюансов, которые как раз выделяют Друпал из ряда других CMS, например, очень сильно влияет кеш запросов и наличие модулей друпала, с другой стороны зависит сколько сайтов Друпал в целом на сервере. Если всего 1 сайт то кеш можно увеличить, если сайтов 200, то кеш запросов вообще лучше отключить так как в нем нет смысла.
Вообщем ваша статья о сферичном коне в вакууме, который кружит вокруг юпитера… как хоть часть вашей статьи связать с жизнью я не вижу, а новички только запутаются еще больше.
Полностью поддерживаю Akuma — Друпалом тут и не пахнет, с таким же успехом можно переименовать статью в оптимизацию Джумлы/вордпресса и в начальных абзацах заменить базовую CMS на другую.
Танцы вокруг memory_limit вообще вгоняют в ступор:
> А вот 128M порой оказывается маловато. Впрочем, это нельзя назвать оптимизацией, это скорее жизненная необходимость.
Вы хоть с Друпалом сталкивались, хоть раз до написания статьи? Друпалу хватит 32-64Мб если сайт настроен и запущен. 64-128Мб если на сайте делают контент с image style, больше 128Мб это если там уже что-то намутили разработчики или сайт специфичен, 256Мб это с запасом для 99% друпал сайтов.
Но в любом случае данный показатель к нагрузке не относится, РНР либо отработает, либо выдаст ошибку, каким образом у вас стало работать быстрее для меня загадка и я с удовольствием почитаю как влияет memory_limit на нагрузку сервера или повышения быстродействия, или почему пиковое потребление РНР сократилось?! Выходит что когда мало памяти было, то у вас часть страниц тупо падало на начале обработки?
Настройка MySQL как-то у вас «по-ламерски» что ли. Тут есть тонна ньюансов, которые как раз выделяют Друпал из ряда других CMS, например, очень сильно влияет кеш запросов и наличие модулей друпала, с другой стороны зависит сколько сайтов Друпал в целом на сервере. Если всего 1 сайт то кеш можно увеличить, если сайтов 200, то кеш запросов вообще лучше отключить так как в нем нет смысла.
Вообщем ваша статья о сферичном коне в вакууме, который кружит вокруг юпитера… как хоть часть вашей статьи связать с жизнью я не вижу, а новички только запутаются еще больше.
Конечно, тема оптимизации затронута поверхностно. Из всей статьи можно выделить только 1 момент — изменение базовых параметров PHP и MySQL для работы Drupal. Не затронуты фундаментальные темы оптимизации сервера. Например установлен оптимизатор кода, но нет ни слова о Memcache или оптимизации веб сервера.
Если хотите углубить тему, то изучите и поэкспериментируйте с этими моментами
1. подключите Memcached, большому сайту на Drupal без него никуда
2. оптимизируйте Apache, также попробуйте вместо Apache и mod_php какой-нибудь fastCGI
3. другие настройки MySQL специфичные под InnoDB, размеры кеша
Drupal 7 использует InnoDB для работы, Drupal 6 MyISAM, для шестого друпала смена типа таблиц очень сильно влияет на производительность, особенно для таблиц Sessions, users, watchdog и другие, куда часто идет запись.
Кстати, как был настроен кеш друпала при тестах?
Если хотите углубить тему, то изучите и поэкспериментируйте с этими моментами
1. подключите Memcached, большому сайту на Drupal без него никуда
2. оптимизируйте Apache, также попробуйте вместо Apache и mod_php какой-нибудь fastCGI
3. другие настройки MySQL специфичные под InnoDB, размеры кеша
Drupal 7 использует InnoDB для работы, Drupal 6 MyISAM, для шестого друпала смена типа таблиц очень сильно влияет на производительность, особенно для таблиц Sessions, users, watchdog и другие, куда часто идет запись.
Кстати, как был настроен кеш друпала при тестах?
У нас было два Оптерона, 16 гигабайт оперативки, 2 гига под мемкеш, полвинчестера свободно и целое множество плагинов и модулей всех сортов и расцветок, а также Апач, MySQL и гигабайт чистого свопа. Не то чтобы это был необходимый набор для Друпала, но если начал писать на PHP, становится трудно остановиться. Единственное, что вызывало у меня опасение — это своп. Нет ничего более беспомощного, безответственного и испорченного, чем свопящийся сервер. Я знал, что рано или поздно мы перейдем и на эту дрянь.
via ibash #16079
Задачу оптимизации работы сервера под Drupal (тогда еще версия 6) я систематически решал в течении длительного времени. Просто перечислю то, что делал, чтобы выдерживать приличную нагрузку при весьма специфической задаче (поддержания электронного сми средней руки) с 14 блоками views только на главной и не менее трех на всех остальных. Помимо упомянутого вами это было:
1. Модуль cacherouter для переключения механизма кеширования с базы MySQL на APC (memcached при этом оказалось слишком прожорливым по ресурсу процессора, по крайней мере на коде годичной давности)
2. Патчем модуля локализации загнал почти все переводы интерфейса в кеш, что уменьшило приблизительно на 40 штук количество запросов к MySQL на страницу. В Drupal7 это сделать легче — достаточно изменить на большое значение одну строку в таблице variables
3. Написал собственный модуль на замену views. Разумеется без всякой универсальности, но достаточно гибкий, чтобы легко добавлять новые старницы и блоки со списками статей по новым тематикам. Главная его задача была в том, чтобы держать результаты в кеше и перечитывать MySQL только если были опубликованы новые статьи или изменено что-то в старых. Кроме того там решалась другая проблема — даже запрос на получение количества страниц в разделе мог занимать более секунды с учетом всех join по нескольким тегам и объема материалов на сайте. В общем там решался большой комплекс проблем, связанный с архитектурными ограничениями Drupal.
4. Глубокая инспекция запросов к MySQL (точнее к MariaDB, у которого изначально чуть лучше с query_cache). Дело в том, что когда количество реальных материалов в базе превысило разумные пределы оперативной памяти (характерная для MySQL проблема), некоторые весьма обычные запросы из Drupal стали выполняться по секунде и более, тормозя не только генерацию конкретной страницы, но и создавая заторы на веб-сервере вплоть до ошибки 502 из-за таймаута при пиковых количествах одновременных посетителей на сайте. В частности запросы поисковиков на страницу № 3000 (архивные для разделов, но индексируемые поисковиками ежедневно), которой нет в query_cache (а быть ее там в любой момент и не может, поскольку индексы по всем необходимым критериям физически не поместились бы в доступную оперативную память), затягивались и на секунду и на 3 и даже, иногда, на 8-10 секунд.
5. По результатам этой инспекции и принято решение о том, чтобы написать свои варианты вместо модулей views и sitemap, а также заменить встроенный поиск на Sphinx search
Был еще вагон различных более мелких оптимозаций, часть которых для Drupal7 не актуальна. В результате холодный (пустые кеши двух уровней) старт стартовой страницы стал занимать 3-4 секунды вместо 40-70 (что весьма вероятно означало ошибку 502 без этих оптимизаций), до 300-450 милисекунд на разогретой базе и заполненном кеше APC.
Из не относящегося к оптимизации Drupal было сделано следующее — LAMP изначально заменен на nginx + php-fpm + MariaDB. Настроен дисковый кеш для nginx на 30 секунд — минуту (специфика оперативных новостей больше не позволяла), что избавило от проблем с пиковыми нагрузками, которые доходили вплоть до 4000 одновременных посетителей (а 200 одновременных посетителей в то время были вполне будничным явлением).
Для большего числа подробностей лучше писать статью, так что дайте знать, если этот опыт актуален.
1. Модуль cacherouter для переключения механизма кеширования с базы MySQL на APC (memcached при этом оказалось слишком прожорливым по ресурсу процессора, по крайней мере на коде годичной давности)
2. Патчем модуля локализации загнал почти все переводы интерфейса в кеш, что уменьшило приблизительно на 40 штук количество запросов к MySQL на страницу. В Drupal7 это сделать легче — достаточно изменить на большое значение одну строку в таблице variables
3. Написал собственный модуль на замену views. Разумеется без всякой универсальности, но достаточно гибкий, чтобы легко добавлять новые старницы и блоки со списками статей по новым тематикам. Главная его задача была в том, чтобы держать результаты в кеше и перечитывать MySQL только если были опубликованы новые статьи или изменено что-то в старых. Кроме того там решалась другая проблема — даже запрос на получение количества страниц в разделе мог занимать более секунды с учетом всех join по нескольким тегам и объема материалов на сайте. В общем там решался большой комплекс проблем, связанный с архитектурными ограничениями Drupal.
4. Глубокая инспекция запросов к MySQL (точнее к MariaDB, у которого изначально чуть лучше с query_cache). Дело в том, что когда количество реальных материалов в базе превысило разумные пределы оперативной памяти (характерная для MySQL проблема), некоторые весьма обычные запросы из Drupal стали выполняться по секунде и более, тормозя не только генерацию конкретной страницы, но и создавая заторы на веб-сервере вплоть до ошибки 502 из-за таймаута при пиковых количествах одновременных посетителей на сайте. В частности запросы поисковиков на страницу № 3000 (архивные для разделов, но индексируемые поисковиками ежедневно), которой нет в query_cache (а быть ее там в любой момент и не может, поскольку индексы по всем необходимым критериям физически не поместились бы в доступную оперативную память), затягивались и на секунду и на 3 и даже, иногда, на 8-10 секунд.
5. По результатам этой инспекции и принято решение о том, чтобы написать свои варианты вместо модулей views и sitemap, а также заменить встроенный поиск на Sphinx search
Был еще вагон различных более мелких оптимозаций, часть которых для Drupal7 не актуальна. В результате холодный (пустые кеши двух уровней) старт стартовой страницы стал занимать 3-4 секунды вместо 40-70 (что весьма вероятно означало ошибку 502 без этих оптимизаций), до 300-450 милисекунд на разогретой базе и заполненном кеше APC.
Из не относящегося к оптимизации Drupal было сделано следующее — LAMP изначально заменен на nginx + php-fpm + MariaDB. Настроен дисковый кеш для nginx на 30 секунд — минуту (специфика оперативных новостей больше не позволяла), что избавило от проблем с пиковыми нагрузками, которые доходили вплоть до 4000 одновременных посетителей (а 200 одновременных посетителей в то время были вполне будничным явлением).
Для большего числа подробностей лучше писать статью, так что дайте знать, если этот опыт актуален.
Актуален. Я бы с удовольствием прочитал хорошую, практическую статью по тюнингу друпала 7. Чтобы в таком стиле — «5 must have пунтктов, которые безболезненно подойдут всем и каждому» + «тонкий тюнинг для продвинутых в разных ситуациях».
«5 must have пунтктов, которые безболезненно подойдут всем и каждому»:
— Не активируйте модули, в которых нет насущной необходимости. Почти любой модуль так или иначе ухудшает производительность
— Не забивайте базу ревизиями
— Уберите из шаблона пейджинга ссылку ">>" (перейти на последнюю страницу)
— Ставьте Recaptcha на формы логина и восстановления пароля
— Не связывайтесь с Drupal, без знания php и без готовности разбираться в его архитектуре.
«тонкий тюнинг для продвинутых в разных ситуациях» требует навыков телепатии.
А вообще я предлагал лишь описание конкретного опыта оптимизации Drupal с учетом недостатков его архитектуры и конкретной задачи повышения производительности на большом количестве данных при высоких требованиях к их актуальности.
— Не активируйте модули, в которых нет насущной необходимости. Почти любой модуль так или иначе ухудшает производительность
— Не забивайте базу ревизиями
— Уберите из шаблона пейджинга ссылку ">>" (перейти на последнюю страницу)
— Ставьте Recaptcha на формы логина и восстановления пароля
— Не связывайтесь с Drupal, без знания php и без готовности разбираться в его архитектуре.
«тонкий тюнинг для продвинутых в разных ситуациях» требует навыков телепатии.
А вообще я предлагал лишь описание конкретного опыта оптимизации Drupal с учетом недостатков его архитектуры и конкретной задачи повышения производительности на большом количестве данных при высоких требованиях к их актуальности.
>«Уберите из шаблона пейджинга ссылку „>>“ (перейти на последнюю страницу)»
Прокомментируйте, пожалуйста. Всегда использую эту ссылку при сёрфинге.
Прокомментируйте, пожалуйста. Всегда использую эту ссылку при сёрфинге.
Всегда использую эту ссылку при сёрфинге.
Поисковики при индексации тоже. А поскольку база данных не часто целиком помещается в память (даже если говорить только о тех таблицах, что задействованы в запросе, сгенерированном модулем views), то по мере роста числа материалов в базе вы столкнетесь с тем фактом, что запрос «SELECT… LIMIT $offset, $items_per_page» при $offset = 100500 будет выполняться существенное время, блокируя другие запросы к базе данных (замерьте сами например здесь habrahabr.ru/posts/collective/page6821/ несколько раз с интервалом не меньше минут 15, чтобы не обольщаться ответом из query_cache). При этом несмотря на вашу, кстати не распространенную, привычку пользоваться этой ссылкой, на большинстве сайтов, существующих продолжительное время (как и в сыше приведенной ссылкой на хабре), пользователям совершенно не актуально начинать чтение с первых материалов, а стало быть и поисковикам незачем давать приоритет для них в индексации, располагая на всех страницах с этим пейджером ссылку на них.
По опыту, поисковики после отключения этой ссылки, перестают давать приоритет индексации древних, не актуальных материалов, а заодно несколькими медленными запросами становится меньше.
Спасибо!
Статья про описание конкретного опыта тоже будет интересна, безусловно.
Статья про описание конкретного опыта тоже будет интересна, безусловно.
Спасибо за обширный комментарий. Опыт всегда актуален, и многие скажут спасибо за такую статью. С интересом почитал бы.
Напишите. Ваш комментарий уже оказался полезнее поста.
Можно еще ЧПУ перенести на Memcached + есть пару модулей кеша для Views
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация сервера под Drupal с замером результатов