Ищу спеца по производительности

Пт, 07/12/2012 - 08:56

Приветствую!

Нужно оптимизировать выделенный сервер Nginx + mysql с сайтом на Drupal 7 для улучшения клиентской производительности и возможности выдерживать высокие нагрузки.

О сайте:

1. под 60000 нод
2. 160+ контент-тайпов
3. Под 1000 полей
4. 155 включенных модулей
5. Автоматический импорт прайс-листов из csv;
6. Поиск и каталог на Search Api + Apache Solr;
7. Drupal Commerce, Display Suite, Context и много более банального;
8. Скромный трафик 200 000 просмотров страниц в месяц;
9. И всё тормозит - несколько секунд на генерацию практически любой страницы, сохранение отображения Display Suite фактически останавливает работу сайта на 3-4 минуты.

В данный момент из оптимизаций используется только APC. С memcache как-то не сложилось, при минимальной нагрузке процессоры заняты на 100%.

Хочется:

1. цель-максимум — чтобы большинство страниц сервер отдавал за 20-30 миллисекунд при нагрузке 5-7 раз выше;
2. оптимальной Настройки MySQL под параметры сервера;
3. то же для php5-fpm и Apache Solr;
4. Внедрения memcache для кэш-таблиц;
5. Внедрения varnish для кеширования статики;
6. Обнаружения и рекомендаций по исправлению проблемных с точки зрения производительности участков кода.

Ищу исполнителя, который совместно с командой разработчиков настроит этот сервер.

0 Спасибо

Комментарии

Аватар пользователя darkdim
4 года 6 months назад darkdim #

Ставим boost

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #
darkdim написал:
Ставим boost

И это тоже пробовали. Всё-же ищем специалиста.

Из забавного — при включенном стандартного кеширования Drupal работает ещё медленнее. Поэтому нужен шаман :)

0 Спасибо
Аватар пользователя darkdim
4 года 6 months назад darkdim #

а почему с memcache не сложилось?

0 Спасибо
Аватар пользователя darkdim
4 года 6 months назад darkdim #

Сколько оперативки на сервере?

0 Спасибо
Аватар пользователя makkon
4 года 6 months назад makkon #

а вы не думали что дело не в сервере, а в том, что некоторые модули, которые вы используете (155 - омг), написаны криво, конфликтуют так или иначе (бета, альфа) и вобще 70% функций в них, которые грузятся, не нужны?

0 Спасибо
Аватар пользователя darkdim
4 года 6 months назад darkdim #
makkon написал:
а вы не думали что дело не в сервере, а в том, что некоторые модули, которые вы используете (155 - омг), написаны криво, конфликтуют так или иначе (бета, альфа) и вобще 70% функций в них, которые грузятся, не нужны?

упс, а еще утечки памяти... и отсутствует закрывающий тег ?> в скриптах. Это все уже проходили. Отключить модуль Core и идти отдыхать? Оптимизацию проводить надо, но в концепции Drupal заложено использование модулей и хочешь, не хочешь, но их использовать нуно. Прежде чем оптимизировать код, нужно иметь оптимально настроенную платформу, а там профилировщик в зубы и вперед.

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #
makkon написал:
а вы не думали что дело не в сервере, а в том, что некоторые модули, которые вы используете (155 - омг), написаны криво, конфликтуют так или иначе (бета, альфа) и вобще 70% функций в них, которые грузятся, не нужны?

В списке хотелок есть пункт №6, так что подумали.

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #

Собственно для решения всех этих проблем я и ищу специалиста.

Если кому-то интересно поработать — welcome.

Оперативки — 16ГБ.

С memcache не сложилось, потому что при его включении загрузка процессоров уходит в потолок и сайт лежит.

Были даже подозрения, что с железом что-то не то, но с memcache те же проблемы и на dev-сервере.

0 Спасибо
Аватар пользователя chilic
4 года 6 months назад chilic #

Пишите ему  RxB">http://www.drupal.ru/username/rxb]RxB[/user]
По некоторым моментам смогу проконсультировать я.

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #
chilic написал:
Пишите ему  RxB

Смущает в профиле "В данный момент - не беру заказы и не консультирую".
А по каким вопросам сможете проконсультировать?
Можно в скайп: val.budkin

0 Спасибо
Аватар пользователя chilic
4 года 6 months назад chilic #
Flinblo написал:
4. Внедрения memcache для кэш-таблиц;
5. Внедрения varnish для кеширования статики;

По такого рода вопросам :) и по остальному.
Контакты в профиле.

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #

Пока поиски приостанавливаю.

0 Спасибо
Аватар пользователя darkdim
4 года 6 months назад darkdim #
Flinblo написал:
Пока поиски приостанавливаю.

а чё так, нашли причину или исполнителя?

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #

Исполнителя.

0 Спасибо
Аватар пользователя cosmos
4 года 6 months назад cosmos #

будет очень интерсено узнать что же вам помогло, пишите

0 Спасибо
Аватар пользователя Ch
4 года 6 months назад Ch #
Flinblo написал:
Под 1000 полей

А сколько у вас таблиц в базе?

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #

Ну, не меньше чем полей. Плюс немного таблиц для модулей. Чуть больше 1700.

0 Спасибо
Аватар пользователя Ch
4 года 6 months назад Ch #
http://drupal.stackexchange.com/questions/16718/fields-scalability написал:
A real problem however is the number of fields you have. Because currently in Drupal 7, the complete field configuration of all fields, no matter if they're loaded or not, is fetched from the cache on every single request.

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

0 Спасибо
Аватар пользователя Crea
4 года 6 months назад Crea #

Подпишусь, пожалуй.

0 Спасибо
Аватар пользователя deb
4 года 6 months назад deb #
Цитата:
2. 160+ контент-тайпов
3. Под 1000 полей

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

0 Спасибо
Аватар пользователя Crea
4 года 6 months назад Crea #

С количеством полей не все так плохо, если они равномерно распределены между типами контента. Меньше 10 полей на тип - вполне может нормально работать.

0 Спасибо
Аватар пользователя Заводской раб
4 года 6 months назад Заводской раб #

это в семерке так туго если 100 полей и более?

в шестерке по моей практике 200 полей визуально на глаз - как будто их и нет.

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #
Заводской раб написал:
это http://www.ktc-ua.com тормозит?

Рассекретили.

Ch написал:
Даже 100 полей на сайте это очень много

Да, я видел это обсуждение на stackoverflow. Но также видел десятка три статей с benchmark-ами, что количество таблиц в mysql не критично для производительности, особенно при наличии переменной table_open_cache. В том числе и от ребят из Percona.

Количество таблиц будет только увеличиваться. Появится 100+ дополнительных контент тайпов, какие-то бейджики и допхарактеристики для мерчандайзинга — и вуаля, их уже под 10000. Если не играться с полями, а приделать костыль — зачем тогда мне Drupal с его замечательным Field Api и Views? Тогда надо перезапускаться на битриксе, owox engine и тому подобном. Интерфейсом настройки карточки товара/каталога должны заниматься контент-менеджеры, а не программисты.

Собственно глобальных проблемы две:

  1. как наладить кэширование до drupal bootstrap в условиях постоянно изменяющихся цен и наличия;
  2. как оптимизировать всё, чтобы двигая поля в DS оно сохранялось резво и без 504 ошибок через раз;

Для пользователя отборы в каталоге и карточки товара должны открываться мгновенно, максимум 100ms без учёта latency канала. Лучше — 20ms. А контентщики должны вьюхи редактировать без матов о том, как медленно всё происходит.

Неглобальных проблем ещё несколько. Memcache какого-то не хочет работать, включение entity_cache приводит к непонятным глюкам и т.д.

Если честно, и я, и разработчики и так перечитались статей по поводу "что ещё можно подкрутить", и за последний год докрутились :)

Поэтому и хочу профи, который знает что к чему и обладает опытом решения подобных вопросов. Можно даже не одного. Скажет, что давайте поля хранить в Mongo — не вопрос. Вопросы только в том как с этим будет работать Search Api и наши кастомные модули.

0 Спасибо
Аватар пользователя Crea
4 года 6 months назад Crea #
Цитата:
Для пользователя отборы в каталоге и карточки товара должны открываться мгновенно, максимум 100ms без учёта latency канала. Лучше — 20ms.

Для Друпала это недостижимая задача, если только не кешировать страницу целиком :)
Снижайте ожидания, или пишите с нуля на фреймворке. Готовые решения вряд ли дадут такую производительность..

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #

Мне очень нравится производительность www.forceful.ru и whitehouse.gov.

Я только за — кэшировать всю страницу целиком, выводя динамические блоки или AJAX-ом или с помощью ESI. Только вот Drupal commerce… Но получается ведь кэшировать у больших зарубежных магазинов на этой балалайке. http://www.drupalcommerce.org/showcase — там есть интересные примеры.

0 Спасибо
Аватар пользователя Crea
4 года 6 months назад Crea #

Дело в том, что кэш не замена правильной архитектуре и оптимизации. Нельзя иметь сайт, который с кэшем открывается за 100мс, а без кэша несколько секунд. Это означает что холодный старт или просто очистка кэша во время работы для такого сайта смерти подобно :)
Лично я вообще считаю кэширование антипаттерном.
200-300мс на генерацию страницы без полного кэша вполне достижимы.

0 Спасибо
Аватар пользователя dgastudio
1 год 7 months назад dgastudio #

у меня как раз сейчас проект, 570 полей на тип содержимого (автомобильная тематика). Все поля были созданы програмно скриптом. Работать все работает, но при попытке перетасовки полей на странице типа содержимого, система уходит в глубочайший аут.

еу

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #
kervi написал:
Работать все работает, но при попытке перетасовки полей на странице типа содержимого, система уходит в глубочайший аут.

Что из best practice оптимизаций при этом используете?

Crea написал:
Лично я вообще считаю кэширование антипаттерном.

И при этом в любом докладе западных drupalcamp-ов про производительность — Cache your cache in a cache which is better to be cached. На какой сколь-нибудь большой и сложный сайт не посмотришь — внешний кэш варниша или nginx, на худой конец boost стоит. Да и warm-up-ы вроде существуют.

Crea написал:
200-300мс на генерацию страницы без полного кэша вполне достижимы.

Достижение этого тоже чрезвычайно интересно. Сейчас всё равно хуже.

0 Спасибо
Аватар пользователя dgastudio
4 года 6 months назад dgastudio #
Flinblo написал:
Что из best practice оптимизаций при этом используете?

только что столкнулся,без понятия. Что посоветуете?

но ответы из поддержки it-patrol довольно таки неутешительные.

Цитата:
Вы могли увидеть, что в данном сообщении(http://www.drupal.ru/node/92738) говориться, что Drupal не сможет корректно работать с количеством полей больше 100. Это действительно так и есть. Если есть необходимость создавать столько полей, то это причина отказаться от Drupala - он не предназначен для решения подобных задач. Я должна вас предупредить, что сайт с подобным количеством полей будет создавать очень большую нагрузку на сервер, а также будет очень сильно тормозить.

0 Спасибо
Аватар пользователя Crea
4 года 6 months назад Crea #
kervi написал:
только что столкнулся,без понятия. Что посоветуете?

Единственный выход это все поля запихнуть в MongoDB. А все потому, что 7 Дру хранит поля в отдельных таблицах, а JOIN тяжелая операция для СУБД.
Вот и доорались, что "Друпал 7 рулит" :)

0 Спасибо
Аватар пользователя Crea
4 года 6 months назад Crea #
Flinblo написал:
Crea написал:
Лично я вообще считаю кэширование антипаттерном.

И при этом в любом докладе западных drupalcamp-ов про производительность — Cache your cache in a cache which is better to be cached. На какой сколь-нибудь большой и сложный сайт не посмотришь — внешний кэш варниша или nginx, на худой конец boost стоит. Да и warm-up-ы вроде существуют.

Естесственно. В Друпале нет возможности коренным образом менять архитектуру, либо это слишком дорого, поэтому все идут по проторенной дорожке - кеширование.
Что касается кэша в варнише и nginx то это все применяется для анонимных пользователей, а с ними то, как раз, проблем и нет практически. Современный сервер с голым кешем Друпала в базе легко отдаст анонимам миллионы страниц в сутки, что с лихвой перекрывает потребности подавляющего большинства сайтов. Т.е. Varnish для большинства сайтов это как пятая нога лошади. Он решает проблему, которой не существует на самом деле. Ну, разве что, страница отдается на несколько мс быстрее - но я бы вряд ли назвал это результатом, достойным геморроя с новым софтом и настройками.
Проблемы у Друпала в другом - тормоза на динамических страницах, где кеширование целой страницы не работает, либо у зарегистрированных пользователей. И готовых решений для таких проблем нет.

0 Спасибо
Аватар пользователя sg85
4 года 6 months назад sg85 #
Заводской раб написал:
это в семерке так туго если 100 полей и более?
в шестерке по моей практике 200 полей визуально на глаз - как будто их и нет.

В 6 поля группировались в одной таблице на 1 материал(за небольшим исключением), т.е. 1 материал = 1 таблица, а в 7рке 1 поле = 1 таблица, и число таблиц довольно плохо сказывается на мускуле, особенно на MyISAM(1 таблица = 1 файл), и кешировании(т.е. при большом числе полей мускул оптимизировать почти бесполезно)

И еще, суть 7рочного подхода: можно одно поле использовать для нескольких типов материала(в 6 тоже так можно, но работало это не совсем так, как нужно), этим можно значительно сократить число таблиц.

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #

Если уж на эту ноду ссылаются как на WhitePaper, вот вам ещё ссылка — http://www.drupal.ru/node/78546.

Интересно, к чему пришли в итоге.

NB. Кто сталкивался с кешированием результата поиска Search Api?

0 Спасибо
Аватар пользователя Ch
4 года 6 months назад Ch #
Flinblo написал:
количество таблиц в mysql не критично для производительности

Я про таблицы и не говорил. Критично кол-во полей. Думаю тормозят не ноды или вьюхи, а именно bootsrap.

Как я понял у вас для каждого типа товара создан отдельный тип содержимого. И все свойства товара реализованы через Field API. Это шаблонный подход. Для вашего сайта он не подходит. Нужно было думать что-то своё. Например, свои типы сущностей и полей, которые учитывали бы особенности номенклатуры ваших товаров.

0 Спасибо
Аватар пользователя EvroHoster
4 года 6 months назад EvroHoster #

Flinblo, обращайтесь к нам. Постараемся Вам помочь. Оплата только за результат.

0 Спасибо
Аватар пользователя Заводской раб
4 года 6 months назад Заводской раб #

а как у вас тут на сайте ktc-ua.com сделано так что когда наводишь на пункт меню например НОУТБУКИ нельзя перейти по этой ссылке, хотя это ссылка, ну понятно что средствами ксс можено сделать ховер эффект вместо лапки сделать стрелку

а можно ли вообще в nice menu, superfish ну или как тут у вас qtip с минипанелями сделать так чтобы верхний пункт меню вообще не был ссылкой?

0 Спасибо
Аватар пользователя natbampo
4 года 6 months назад natbampo #

Заводской раб, для этого есть  special_menu_items

0 Спасибо
Аватар пользователя imarat
4 года 6 months назад imarat #
Заводской раб написал:
а как у вас тут на сайте ktc-ua.com сделано так что когда наводишь на пункт меню например НОУТБУКИ нельзя перейти по этой ссылке, хотя это ссылка, ну понятно что средствами ксс можено сделать ховер эффект вместо лапки сделать стрелку

(function($){
$('#ид_пункта меню').children('a').click(function(){
return false;
});
})(jQuery)

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #

Что-то в этом роде, ага.

0 Спасибо
Аватар пользователя Заводской раб
4 года 6 months назад Заводской раб #

в целом уже разобрался

 special_menu_items и прочие фигни пробовал, не работают

например найсменю или суперфиш привязаны к селектору ссылке и поэтому qtip с минипанелями не срабатывает, хотя сами суперфиш/найсменю работают

 menu_item_container вроде ниче так, в найсменю/суперфиш выводится пункт без ссылки

 menu_firstchild кал еще тот

0 Спасибо
Аватар пользователя volocuga@drupal.org
4 года 6 months назад volocuga@drupal.org #
Flinblo написал:
1. под 60000 нод
2. 160+ контент-тайпов
3. Под 1000 полей
4. 155 включенных модулей
5. Автоматический импорт прайс-листов из csv;
6. Поиск и каталог на Search Api + Apache Solr;
7. Drupal Commerce, Display Suite, Context и много более банального;
8. Скромный трафик 200 000 просмотров страниц в месяц;
9. И всё тормозит - несколько секунд на генерацию практически любой страницы, сохранение отображения Display Suite фактически останавливает работу сайта на 3-4 минуты.

Походу мне предстоит столкнуться с тем же скоро :) Flinblo - давайте дружить :)

Имхо, яркий пример того, что Друпал таки сосёт. Жаль юзер Андед, слепой друпал-евангелист, помер, а тоб живо заткнулся :)

0 Спасибо
Аватар пользователя volocuga@drupal.org
4 года 6 months назад volocuga@drupal.org #

Импорт из csv - самопись либо классический feeds?

0 Спасибо
Аватар пользователя multpix
4 года 6 months назад multpix #

да уж search_api вкусняшка...
ну как там прирост производительности от оптимизации?
ресульт в студию!(интересно жыжж)

search_api_ajax на многих стр. срабатывает(в бесконечность) - хотя на них не нужен...

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #
volocuga@drupal.org написал:
Импорт из csv - самопись либо классический feeds?

Всё своё, feeds — ужасный тормоз.

multpix написал:
да уж search_api вкусняшка...
ну как там прирост производительности от оптимизации?
ресульт в студию!(интересно жыжж)
search_api_ajax на многих стр. срабатывает(в бесконечность) - хотя на них не нужен...

В процессе оптимизации.

От Ajax в каталоге будем отказываться, для SEO это плохо. За исключением twitter-like листалки страниц.

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #
volocuga@drupal.org написал:
Походу мне предстоит столкнуться с тем же скоро :) Flinblo - давайте дружить :)
Имхо, яркий пример того, что Друпал таки сосёт. Жаль юзер Андед, слепой друпал-евангелист, помер, а тоб живо заткнулся :)

Свет в конце туннеля виден. Но "на Drupal всё быстрее и дешевле, чем на (подставьте фреймворк/самописку/коммерческую cms)" это всё-таки миф. Долго, дорого и с костылями.

Но как читаешь форумы какой-то magento — там все те же проблемы. Bitrix — аналогично. А на самописке мы жили когда-то, зависеть от "уникального разработчика" никому не советую. Хотя резвенько работало, не спорю.

0 Спасибо
Аватар пользователя Crea
4 года 6 months назад Crea #

Любая фирма, бизнес-процессы которой завязаны на технологии, предпочитает иметь постоянных специалистов. Потому что ядро бизнеса должно быть in-house, иначе это не бизнес а черти что. Зависит ли она - да. Проблема ли это - да. Нужно ли с этим бороться - не факт.
"уникального разработчика" может не быть, но это зависит не от технологии прежде всего, а от технологических процессов, методологии. Drupal дает стандарты и культуру разработки, но не является гарантией, что они будут корректно применены в вашем проекте.

0 Спасибо
Аватар пользователя multpix
4 года 6 months назад multpix #
Flinblo написал:
От Ajax в каталоге будем отказываться, для SEO это плохо

поясните, интересно мнение.
у самого подобные пути (с # и без) + сеошник с мнением что это суперхорошо без аргументов

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #
multpix написал:
у самого подобные пути (с # и без) + сеошник с мнением что это суперхорошо без аргументов

Потому что ссылка http://www.ktc-ua.com/catalog/notebook#path=manufacturer/dell-83 без включенного яваскрипта ссылается на страницу каталога со всеми ноутбуками, а не ноутбуками Dell. Соответственно при естественном росте ссылок страницы отборов фактически не продвигаются.

0 Спасибо
Аватар пользователя Flinblo
4 года 6 months назад Flinblo #
Crea написал:
Любая фирма, бизнес-процессы которой завязаны на технологии, предпочитает иметь постоянных специалистов. Потому что ядро бизнеса должно быть in-house, иначе это не бизнес а черти что. Зависит ли она - да. Проблема ли это - да. Нужно ли с этим бороться - не факт.

Спорно. Мы сами многое аутсорсим для других компаний. Малому бизнесу свои айти-специалисты просто не по карману. И многим выросшим проще нанимать контрактников. Всё зависит от стратегии выбранной руководителями.

Но это уже лирика.

0 Спасибо

Страницы