11 апреля 2008 в 0:49
Тезисы и комментарии.
Основаваюсь на собственном (не очень большом) опыте разработки большого портала на Друпал. Сразу извиняюсь за стиль - наболело
Разрабатываем портал, в котором изначально будет 20тыс нодов и 120тыс комментариев. И пусть 5000 посетителей в день.
Какой сервант под это потребуется или как нужно извратиться над Друпалом, чтобы это пошло на VDS1024 ?
0.Включаем стандартный кэш.
Без кэша вообще делать не чего.
0.1 ставим нормальный уровень кэша
0.2. можно включить повышенный стандартный кэш, но он не совместим с ССК. т.е. сразу отбрасываем этот вариант (?)
0.3. ищем на сайтах все что может относится к кэшированию и думаем как это можно применить для конкретного сайта и даст ли это производительность:
* файловое кэширование
* мемкэш
* кэш блоков
* статическое хранение страниц
* и т.д. и т.п.
1. Встроенная система хранения кэшированной информации и сессий никуда не годится.
Что за постоянные запросы на обновление, добавление и удаление в огромных таблицах по не числовым не инкрементным ключам. При не большой посещаемости и достаточно большом сайте обращение к таблицам сессий и кэша полностью останавливает работу сервера, поскольку индексы таблиц постоянно пересчитываются.
Решение:
1.1. Хранить кэши и сессии в мемкэше
- Есть он не на всех хостингах,
- Демонов придется поднять несколько (либо извратиться и изменить модуль мемкэша), иначе всплывают глюки вида: сохранили один тип конента, очистили другой - очистилось все (из-за особенностей мемкэша), и так по кругу. Можно конечно попробовать все такие места постараться найти и изменить порядок очистки и установки значений.
- Необходимо отслеживать прожорливость такого способа хранения информации - память не безграничная, а если будет маленький процент хитов и большой вытеснений, можем свести на нет все преимущества кэширования
1.2. Альтернатива: изменить тип таблицы с MyISAM на Innodb
- не факт что поможет и станет работать быстрей, но явных блокировок не будет
1.3. Попробовать тип Memory для таблицы сессий
- вполне может привести к переполнению
1.4. Нафига хранить сессии неавторизованных пользователей?! В том числе и ботов, это же туева куча лишних запросов на изменение таблицы и не понятно зачем...
- честно сказать, еще не пробовал поменять логику в ядре, и пока одна надежда на мемкэш - покрайней мере должен сгладить эту проблему.
2. Система алиасов
Что за система алиасов, которая на странице может генерировать на обычном сайте с форумами и комментариями до 100-200 запросов?
Решение:
2.1. Отключить алиасы...
- Замечательно решение 8/ В топку тогда все сайты на друпале
2.2. Самому формировать урл, не обращаясь к функции L()
2.3. Опять одна надежда на - мемкэш,
- правда придется лезть в ядро и применять плагин какого-нибудь стороннего модуля, или самому подправить несколько строчек рядом с формированием запросов к б.д. в файле path.inc.- это уже дело техники...
3. Представления
Смотрели какие запросы генерируются? а план запросов?.. Для запросов чуть сложнее, чем самый простой и при большом объеме данных получаем коллапс. Напрмер
explain SELECT DISTINCT(node.nid), node.changed AS node_changed_changed, node.title AS node_title, node.changed AS node_changed, users.name AS users_name, users.uid AS users_uid, profile_nick.value AS profile_nick_value, profile_hero.value AS profile_hero_value, node_comment_statistics.comment_count AS node_comment_statistics_comment_count
FROM node node
INNER JOIN users users ON node.uid = users.uid
LEFT JOIN profile_values profile_nick ON users.uid = profile_nick.uid AND profile_nick.fid = '11'
LEFT JOIN profile_values profile_hero ON users.uid = profile_hero.uid AND profile_hero.fid = '12'
LEFT JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid
WHERE node.type in ('forum' , 'blog')
ORDER BY node_comment_statistics_comment_count asc
LIMIT 0, 30;
;
На 20000 записей и время запроса 3 секунд- вроде бы абсолютно стандартный запрос для портала - последние записи, отсортированные по дате последнего комментария
Решение:
3.1. Не делать выборки по нескольким типам 8/ - наверно поэтому на сайте Друпал.Ру два блока с сылками на последние записи, а не один...
3.2. Не делать сортировку по таблицам, по котором не фильтруются записи (особенности mysql да и большинства других б.д. насколько я знаю)
- что.ж можно заменить дату комментирования на дату обновления, или добавить свое поле в таблицы с нодами, в котором хранить дату комментария. КТо-нибудь делал?
3.3. Стараться избавляться от Left Join Если он не нужен (спорно, в некоторых случаях наоборот )
- видать нужно лезть в модуль "Профиль", и там править его функции работы с видами. Кто знает?
3.4. Вид при добавлении колонок из профиля добавил дистинкт.
Кто знает как его убрать? В этом случае он нафиг не нужен. (Наверно так же в модуль "профиль")
3.5. Выкинуть нафиг модуль представлений...
- Но тогда и весь друпал в топку отправить, если у вас нет выделенного мощного сервера или нескольких серверов.
3.6. Кэшировать блоки.. Но кто-то же из пользователей будет ждать эти 2-3 секунды... А при постоянных операциях чтения-записи кэш будет часто сбрасываться.
3.7. добавить свое поле в таблицу нодов, в которое поместить ИД группы типов записей (блог+форум, новости + статьи, и т.п.)
4. Функциональный код с глобальными переменными.
Прошлый век... Точнее еще 10 лет назад говорили что так писать нельзя. Особенно когда задействовано много модулей и их. Язык то позволяет писать более красиво и понятно
5. Вывод
Будь проклят тот день, когда собрался делать большой проект на друпале, купившись на то что большинство требуемых модулей уже реализовано...
5.1. Затраченное время на анализ тормозов и способов их устранения при ограниченных денежных ресурсов, вполне могли пойти на разработку портала, специлизированного и оптимизированного под нужную функциональность, причем без всего лишнего.
5.2. Выйгрыш минимальный... - пришлось во многих модулях что-то подкручивать, из-за чего автоматическое обновление не возможно и стоимость поддержки проекта вырастает. Казалось бы опен-сорс сообщество это хорошо. На деле - в такой стандартной проблеме как скорость работы не нашел подробного документа со всеми рекомендациями, а только куча разрозненного и сторонних модули, которые правят ядро.
5.3. Простой модуль, не понятно кем написанный и для каких собственных нужд - в вашем случае может завалить весь сервер
5.4. Делаете большие сайты на друпал, только если
* у вас есть деньги на железо или оочень хроший хостинг
* если большая часть операций - это чтение
* если вам не нужно использовать множество модулей, а только основные
* если вам нравится стандартный дизайн, или вам достаточно сменить цветовую схему. Для чего-то изысканног - ищите хорошего верстальщика, который умеет верстать под друпал
* если вы фанат процедурного программирования и не имеете ничего против глобальных переменных
* если вам больше нравится изучать КАК это работает, чем самому реализовывать.
5.5. Если вы не писали сайты под друпал, то не делайте сразу большой проект, даже если у вас есть советчики, которые говорят что все "будет хорошо", как минимум 1-2 законченных маленьких и средних проектов, на которых вы набъете шишки.
Я буду рад, ксли мне укажут где я был не прав, дадут ссылки на обобщенные методы оптимизации сайтов на друпале. Давайте только не спускаться до уровня - "Сам дурак".
Комментарии
Много чего надо делать, но очень мало КАК это сделать.
А вообще, 5к посетителей, это макс для друпала без существенных накруток.
- да, в основном вся информация разрозненная, и в половине случаев не применима
- держится же drupal.org и drupal.ru
1. InnoDB помогает. Я не спец в методах хранения данных в БД, но после перевода таблицы сессий и кеша в InnoDB сайт начал шевелиться шустрее, и пропали редкие, но болезненные креши таблицы сессий.
2. Для модуля path на друпал.орг я находил патч. Хотя проблема давняя и больная, Дрис включил ее решение только в версию 7. Консерватизм конечно хорошо, но не до таких пределов... А для гостей все равно страница берется из кеша целиком, одним запросом.
3. Если есть время и силы, не использовать Views, а лепить свои модули с оптимизированными запросами. Все равно в других фреймворках пришлось бы делать то же самое, но в них нет Views
4. Согласен, что железо/хостинг решают.
я написал им на drupal.org багрепорт что чем они думали когда выбирали MyISAM для сессий!!! MyISAM отличается тем что когда добавляется запись - а она добавляется всегда когда идет запрос страницы - то таблица блокируется для всех полностью и никто больше сайт посмотреть не может - то есть в одно время сервер может отдавать страничку только одному пользователю - если время генерации страниц около секунды-двух то в не зависимости от производительности сервера получается конструктивный предел в один пользователь в 2 секунды - при чем если будет больше - то сайт будет висеть абсолютно и полностью для всех пока запросы не прекратятся, а они не прекратятся потому что идут от поисковиков, и пока не пройдет определенное время, но это еще пол беды - беда в том что при превышении этого предела происходит лавинообразное накопление очереди коннектов которая займет все ресурсы сервера множеством коннектов и повиснет все у всех - собственно это и наблюдается на серверах с друпалом.
с багрепортом у них хватило ума не спорить, только сказали что подумают про это в других версиях
kiev1, самому если пересоздать таблички, всё ок будет?
- пока такого же мнения, но и при этом типе таблицы, постоянно висят запросы к таблице сессий и кэшей
- видел штуки 3 разных патча, в итоге пока написал свое решение - через стандартные функции работы с кэшем, но при использовании memcached
В этом все и дело... Если нет CCK и Views, тогда друпал НЕ НУЖЕН ВООБЩЕ для не шаблонных сайтов, а может и для большинства шаблонных - в каждом из них приходится добавлять новые свойства к хранимым объектам и делать выборки с сортировками....
Опытному программисту проще самому реализовать большой проект на известном поддерживаемом фреймворке и СВОЙ код оптимизировать под конкретные нужды.
два бэкэнда с апачом+ 1 база на raid 10/50 из sas
Это для какой нагрузки и для какого сервера подойдет?
А что если планируется посещаемость 20000 человек для сайта с блогами и форумами?
HP380 с 4х ядерным ксеоном и 4 гб памяти в нормальной комплектации порядка 300 т.р.
Хватит такой железяки, или еще более мощный сервер нужен, например под б.д.?
не хватит, конечно. если больше 4-5к уников, но нужно как минимум 2 сервера: фронтэнд+бекэнд с nginx+apache+eaccelerator/apc+статика и сервер БД с RAID 10/50 из scsi/sata.
вот я щас делаю проект на 15к, посмотрим осенью, как он себя поведёт
там по железу от 3-х серверов плясать будем
Смотря как настроите. у меня двухядерный с 2 гигами оперативки держат сайт с 20-25 тысячами
Читал и думал - как хорошо, что у меня не весь сайт на друпале
(у меня vps)
А то бы с моими 6к, я бы повесился уже
P.S. Все таки нужно что то делать с производительностью
Не делать выборки по нескольким типам
Это действительно так?, то есть лучше сделать 2 блока по 10 последних нод (ноды разных типов), чем сделать один на 20 последних нод обоего типа
Я что-то не совсем понимаю, в обсуждении имеется 5000 посетителей - залогиненых посетителей? Или все-таки просто посетителей?
Друпал с кучей модулей + Accelerator + 2 гига оперативы вполне себе потянет проект и на 10000 в день. Самая большая проблема - это не просто юзеры, а залогиненые юзеры
преобразовать очень просто ALTER TABLE ... TYPE=INNODB
ну да разделяю депрессивное отношение к друпалу только если речь идёт о 5000 залогиненных причём одновременно
теперь по порядку:
кэш
включаем стандартный кэш.. обязательно!
кэш блоков.. модуль кривой, я не использую.. 6-я версия пока на очереди
мемкэш.. без него пока лучше
Встроенная система хранения кэшированной информации и сессий никуда не годится.
Ни разу не думал об этом, описанной вами ситуации не наблюдаю.
Система алиасов
не испытываю никаких проблем от включения этого модуля.. патч в реальных условиях особо ничего не дал.. предпочитаю не патчить движок и сторонние модули
теперь о выводах...
Не делать выборки по нескольким типам 8/ - наверно поэтому на сайте Друпал.Ру два блока с сылками на последние записи, а не один... про друпал.ру гы гы
Затраченное время на анализ тормозов и способов их устранения при ограниченных денежных ресурсов, вполне могли пойти на разработку портала, специлизированного и оптимизированного под нужную функциональность, причем без всего лишнего.
это сколько же вы времени потратили? во сколько оцениваете разработку своего портала?
Выйгрыш минимальный... - пришлось во многих модулях что-то подкручивать, из-за чего автоматическое обновление не возможно и стоимость поддержки проекта вырастает. Казалось бы опен-сорс сообщество это хорошо. На деле - в такой стандартной проблеме как скорость работы не нашел подробного документа со всеми рекомендациями, а только куча разрозненного и сторонних модули, которые правят ядро.
мне не пришлось хакать ни один модуль, проект абсолютно не шаблонный.. видимо вы не правильно подошли к разработке портала.. ха а может ваши правки отчасти виноваты в тормозах?
Простой модуль, не понятно кем написанный и для каких собственных нужд - в вашем случае может завалить весь сервер
не стоит пугать людей, таких ситуаций практически не бывает и решаются они несложно.. конечно желательно делать всё аккуратно и заниматься самостоятельным бекапом перед установкой новых модулей
Делаете большие сайты на друпал, только если
* у вас есть деньги на железо или оочень хроший хостинг
* если большая часть операций - это чтение
* если вам не нужно использовать множество модулей, а только основные
* если вам нравится стандартный дизайн, или вам достаточно сменить цветовую схему. Для чего-то изысканног - ищите хорошего верстальщика, который умеет верстать под друпал
* если вы фанат процедурного программирования и не имеете ничего против глобальных переменных
* если вам больше нравится изучать КАК это работает, чем самому реализовывать.
этот пункт всецело спорен.. опять же всё познаётся в сравнении.. лично я всем и всегда советую делать сайты на друпал и абсолютно уверен, что это - будущее cms
особенно хотелось бы выделить это:
* если вам нравится стандартный дизайн, или вам достаточно сменить цветовую схему. Для чего-то изысканног - ищите хорошего верстальщика, который умеет верстать под друпал
извените меня. если у вас проблемы с css резонно будет подумать о смене рода деятельности.. имея не малый опыт именно в вёрстке под различные системы смею заметить, что не встречал более удобной системы темплейтов, особенно это ощущается после разработке нескольких проектов.. сейчас доходит до абсурда.. создать темплейт и установить друпал проще, чем делать пару html страничек.. пока дримвейвер по скорости выигрывает только при создании именно одной страницы..
Разрабатываем портал, в котором изначально будет 20тыс нодов и 120тыс комментариев. И пусть 5000 посетителей в день.
Какой сервант под это потребуется или как нужно извратиться над Друпалом, чтобы это пошло на VDS1024 ?
вопрос, что такое VDS1024? это какаято абсолютная величина??
моя ситуация:
почти 28000 нодов
153124 комментарий отправил только что..
6-9 тысяч уникальных посетителей в день
35-45 тысяч просмотров в сутки
почти 8000 зарегистрированных пользователей
онлайн (кроме глубокой ночи)
40-70 залогиненных 80-150 гостей
используется только встроенное кэширование + nginx + eaccelerator
никаких оптимизаций запросов не производилось
сторонних модулей ооочень много
все страницы кроме блогов и форумов - cck+views
сервер - 20% двухядерного ксеона 1024 оперативки sas диск (последнее важно по моим наблюдениям не меньше чем процессор)
ссылка на записи истории оптимизации сервера http://drupal.ru/node/10092
ну ещё хотелось бы услышать мнение автора.. скажите, у вас действительно проблемы с окупаемостью проекта с 5000 хостами? может быть вы применяете не хорошие методы "раскрутки".. а много у вас просмотров? как давно создали портал? может попробуете поставить контекстную рекламу вместо выплёскивания недобрых отзывов о самой замечательной системе?
просто мне кажется все недостатки, которые вы привели применимы к любой доступной системе, это общие недостатки всего современного по и железа кстати и мне кажется вы слишком занижаете стоимость разработки подобных проектов с нуля..
--------------------
а теперь вопрос ко всем:
тип таблицы в любое время можно изменить? прям в майадмине? имею ввиду - MyISAM на Innodb.. эта операция обратима?
...
3) А что вы ждали от не оптимизированной системы? Что она сама будет 100% правильно строить планы запросов(если они поддерживаются MySQL) во всех возможных случаях ? Странно... В любой SQL системе это самое "тонкое место"
3.1) не понял... примерчик бы...
3.2) Это вопрос или утверждение? RTFM вроде как везде - вначале фильтруем, потом сортируем(можно во вложенном запросе). У кого проблемы?
3.3) Странно, если мне валенки не нужны я их не покупаю.
3.4) ... 3.6) ....эмоции
4) Чистится из версии в версию.
5) Странный подход. Бюджет - определяет результат. Есть бюджет - наймите специалистов.
Пусть напишут ваше узко специализированное решение. Если нет - что вы хотели получить? Где ошибка?
Надеюсь вам примеры успешных проектов(с большим трафиком) приводить не нужно.
Некоторые решения описаны на org сайте. Все они были сильно "донастроены".
Естественно "народный авто" в ралли и чемпионате по перевозу тяжестей врядли быдет таким же как специализированные авто...
>никаких оптимизаций запросов не производилось
Правда пришлось отключить модуль advanced forum. Уж слишком жрущий запрос там оказался. Может у меня появиться время и попытаюсь оптимизировать этот запрос позже....
3.3. Стараться избавляться от Left Join Если он не нужен (спорно, в некоторых случаях наоборот )
а что такое Left Join ?
Это когда объединяются в запросе 2 и более таблицы.
Если это делать необдумано, как, например делает автор поста, то можно получить 20000 записей, потом их отфильтровать, а затем выбрать 20...
alexweb, причём это всеголишь новая версия модуля в которой попытались внедрить темизацию всех компонентов форума и не протестировали при большой нагрузке.. к тому же модуль в альфа версии.. тоесть раньше с ним проблем не было как и большинства функций.. я решил эту проблему по другому, хотя у форума до сих пор есть огромный косяк..
Valeratal, присоединиться к левым
ну перевести я перевел
вправо чтоли?
А где "та кнопка"
а куда надо приосоединятся
Прочитал внимательно, понял что про запросы SQL - но не понял как это применять
Вообще, давайте как то конструктивнее Есть проблема - есть такое решение. А то описание проблем и никаких вариантов решения. Прямо стена_плача
Вот у clubwave.ru есть хорошая тема в этом смысле
P.S. А что такое "дистинкт"
Valeratal
если на пальцах - LEFT JOIN (RIGHT) = SELECT * FROM XXX WHERE x IN (SELECT * FROM YYY)
Надо выбрать ноды, которые принадлежат определенному термину.
SELECT * FROM {node} n WHERE (n.nid IN (SELECT nid FROM {term_node} where tid = 1))
Кривой запрос, действительно, может неслабо базу нагрузить.
DISTINCT - убирает повторы в результатах.
Есть результат в виде (и есть, допустим поле Z, которое ваще не участвует в выборке, но отличается значениями):
X Y
1 50
2 50
2 50
3 10
3 10
1 50
Дык вот, с DISTINCT будет
1 50
2 50
3 10
PVasili, а можно подробней?
например у меня есть вьюс, заменяющий тракер, вполне возможно я получаю 20000 записей, потом их отфильтровываю, а затем выбираю 20...
какие действия нужно предпринимать при создании вьюва, и какие предпринимать не стоит, чтобы не оказаться в подобной ситуации?
дистинкт без надобности как я понял во вьюсе тоже лучше не ставить?
Valeratal, дистинкт - фильтр вьюва, который проверяет ноду на уникальность.. я примерно так это вижу.. а ты чего в аське не общаешься?
clubwave.ru
Повкуривать мануалы по mysql, а потом просто логически хорошо продумать запрос. Лучше не потом отфильтровывать, а сразу же, в запросе указать необходимые критерии.
KCEOH, на примере можете показать как можно при помощи вьва неправильно построить запрос а как правильно?
имеется ввиду, что играет роль в каком порядке фильтры добавлять?
на картинке вьюв, который запрашивают 2000 раз в день авторизованные пользователи
правильно ли выставлены фильтры и скажем если добавить фильтрацию по таксономии, что изменится с точки зрения использования базы?
Ну конкретно про VIews я ничего не скажу - имел в виду именно запросы SQL, которые пишутся руками.
Как вариант - включить модуль devel, и посмотреть что больше всего жрет времени, поиграться с настройками.
Один из вариантов улучшения запроса - вырубить проверку на опубликованность. На деле очень редко бывает, что ноду оставляют "на потом". И такое чаще всего для админов / модеров, простой юзер обычно при создании топика / записи в блоге должен его публиковать.
вообще то это все не то
дело в том что не нужно для каждого посетителя несколько раз из базы строить странички и выборки! достаточно один раз построить до момента пока эта страничка не поменяется!!!
в комерческих CMS так и сделано - отдельно кешируется все то что отдельно обновляется, потом из всего этого - из готовых лежащих на диске файлов!, строится полная страница! Я не понимаю в чем вообще проблема создателей друпала сделать нормальный кеш? А то они сами запутались в трех соснах наподобие с Form-API с которым носятся и меняют теперь от версии к версии с которым непонятно как и зачем разбираться когда есть обычные нтмл теги.
Так и кеш - логика кеша давным давно проработана и проста - определяются составные части страницы которые меняются отдельно - отдельно строятся, отдельно пишутся на диск и только в конце соединяются в готовую страницу - ну что-же тут невероятно сложного?
вот пример сайта на такой самой обычненькой средненькой CMS системе которую не ахти какие спецы делали - даже капчу поленились прикрутить, а кеш как ни странно сделали - на сервере несколько таких довольно нагруженных сайтов - загрузка сервера нулевая, базу он вообще не трогает, сервер стал загружен только когда на нем появилось пару мало посещаемых сайтов на друпале.
Почему этого элементарного не смогли сделать разработчики друпал за 5 (!) лет - просто какая то загадка! Уже дошли до того что пишут отдельные модули - и вместо базы на диск и просто на диск и локализацию выносят на диск и алиасы на диск и патчи и т.д. - да все как-то не впопад! все никак не могут догадаться до элементарного... - когда говоришь что кеш не должен сбрасываться пока не обновится породившая его страничка - делают круглые глаза и думают потом - а чего это оно все виснет и виснет и конца этому нет - только в 7-м запланировано... что-ж там планировать: блоки просчитать - на диск, контент из базы вытащили - на диск, комменты пособирали к ноде - на диск - в конце все собрали и все.
А по какому принципу планируется определять, что сбрасывать, а что нет?
При изменении одной ноды напрочь неизвестно, какие блоки/страницы обновлять... особенно страницы с выборками-сортировками
А вот вариантов кеширования существует достаточно много и какой-то один считать правильным - ошибочно. В каждой задаче свое решение.
Альясы и переводы на диск|mem тоже не всегда полезно - память тоже не резиновая, выборка альяса кешируется базой - это копеечные запросы.
При изменении одной ноды напрочь неизвестно, какие блоки/страницы обновлять...
естественно обновлять только ноду и только те блоки в которых в результате что-то изменилось.
алиасы и переводы на диск это совсем не умно - так как потом они все оказываются все равно в памяти.
а вот хотя бы чистые ноды и блоки на диск - это было бы правильно.
А как определить, в какие блоки она попадет и тем более вьюсы...
Порой и на диск полезно, например, когда языков несколько - в память будут попадать только используемые
Что значит чистые ноды? Например для одного пользователя разрешен просмотр загруженных файлов, а для другого нет - так как кешировать ноду?
А к этому стоит добавить, что для разных пользователей могут быть разные темы и что в таком случае кешировать?
www.gen.su
до 5К уников в сутки(единовременно до 250 видел)10-15К просмотров в сутки...используется и views и CCK....и собстно всё что только нужно...материалов примерно 20К
для производительности:
- boots (с средним кешированием)
- блоккеш вырубил...слишком много глюков
- Javascript Aggregator (жмет JS)
- стандартное сжатие CSS
Сервер отдельный 2К памяти...двухъядерный P4 - 3,2 (1200$ копейки для крупного портала)
разницу между 100 уников и 5К не заметил...тормозов нема...
З.Ы.: абсолютно лишняя паника...если при 20К уников сервер начнет гнуться - за 800$ поставлю второй сервак рядом под мускуль...и до 30-40К в сутки можно не париться...Друпал в данном случае показывается себя офигительно...
залогиненых юзеров одновременно не более 10...сайт всё же статейный...и коменты народ пишет из статей напрямую на форум punBB, а уж из форума коменты к каждой ноде поддгружаются...стандартные коменты не используются...
а как работает кэш в модных cmf? или там его самому организовывать нужно?
мне нравится подход danger4k!
ёмаё ну уж если у вас на сайте зарегенных куча сидит, ну неужели на сервак денег не наберётся?
а если сайт просто для чтения, так там вообще nginx и акселератор воткнуть и никаких проблем не будет.. у меня ваще на шаредах такие сайты..
и ваще компы развиваются очень быстро, скорона шаредах можно будет огромные проекты хостить и не париться..
kiev1, я считаю ваши наезды в сторону разработчиков друпала необоснованными, на самом деле вы лишь поверхностное представление имеете о том, почему в друпал такая система кэширования и начинаете приводить в пример какието другие системы или вообще узкоспециализированные движки. Мне лично даром не нужно менять друпаловские возможности на какуюнибудь систему кэширования, более "умную" для какогото одного проекта..
KCEOH, ок будет желание буду пробовать..
А всем кто читает тему и опасается за будущее своих проектов хочу сказать - не парьтесь!! меняйте хостинг если у вас проблемы.. нормально всё с друпалом! альтернативы нет и нафиг не нужна!
каждая новая версия всё легче, удобней и функциональней..
А как определить, в какие блоки она попадет и тем более вьюсы...
во вьюсах с кешированием проще - там в теме при выводе можно прописать логику кеширования, но если не особо думать то блоки можно пересчитывать заново, их на сайте гораздо меньше чем страничек
Например для одного пользователя разрешен просмотр загруженных файлов, а для другого нет - так как кешировать ноду?
конечно кешировать поля ноды отдельно - собираются то они все равно в шаблоне.
а вообще есть такая интересная штука smarty и в друпале даже есть ее поддержка, вышеприведенные сайты как раз на ней сделаны, может если ее подключить к друпалу то проблемы с кешированием можно решить?
наезжаю я на разработчиков по причине того что нода должна кешироваться отдельно от блоков комментов и других частей и не должен кеш ноды меняться пока не изменится нода - вот и все, наверно есть смысл встроить кеш в CCK
Ну вот, уже лучше
Теперь давай-те посмотрим на кеширование частей ноды внимательно! нафига нам кешировать массив/объект части ноды, когда он выбирается из базы очень легким запросом по первичному индексу NID, посмотрите внимательно на хук nodeapi в операции load - по NID подтягиваются дополнительные поля ноды, определяемые данным модулем - запрос легок! Так зачем же кеш, когда можно получить первичную информацию за ту же стоимость, что и сериализация массива/объекта. Можно конечно поспорить о количестве востребованных данных, например, зачем в node_images загружаются все изображения прикрепленные к ноде, когда в тизере используется только 1-2 из них 
Но на этапе загрузки ноды она не знает, в каком контексте она будет выводиться - поэтому после полной загрузки ноды она складывается в кеш(статический массив) - дабы не загружать её целиком при повторном обращении например из блока.
Smarty как движок темизации есть для друпала, но он просто отъедает процессорное время - эффективность его как правило намного ниже чем php print, теперь добавьте дополнительный disk I\O на подтягивание файлов шаблонов и их кешированных копий - картина совсем безрадостная...
Все таки, уважаемый kiev1, вы плохо знакомы с архитектурой drupal ... Вы оперируете понятием нода, кеш ноды, добавить кеш в ССК. Вы так и не ответили на мой вопрос, как же быть со снипетами, которые не вызывают node_load? Вот вам простой пример:
есть пара блоков, которые выводят, например, последние измененные материалы и самые читаемые материалы
Реализуются они довольно тривиальным запросом с сортировкой результатов, так вот когда нужно перезапросить данные для этих блоков? На этот вопрос может быть несколько ответов, и все они будут начинаться с фразы: "В случае..."
Поэтому любой проект оптимизируется по своему, и универсального решения "на блюдечке" не существует. Собственно, как и универсальной настройки базы данных.
Друпал чаще требует настройки базы для частых мелких транзакций и большого количества запросов по первичному ключу.
наверное, но в тоже время кэш полной страницы даёт очень хороший результат при показе сайта десяткам тысяч гостей
Ну вот, уже лучше
Теперь давай-те посмотрим на кеширование частей ноды внимательно!
да, это в зависимости - какое назначение сайта - если это один сайт на одном сервере - то претензий к друпалу нет - работает и ладно, а вопрос идет не о одном сайте на одном сервере а о сотне сайтов на одном сервере и одной безе данных.
в этом случае node_load не лучший вариант запроса каждый раз страницы, во первых при исполнении php он отъедает памяти больше чем все вместе взятые объекты вытянутые из базы (лимит памяти на хостинге не безразмерный), во вторых вытягивать из базы каждый раз страницу неправильно по той лишь причине что разделить процессорные ресурсы между пользователями намного проще если они работают с диском а не с базой - точнее сказать разделить ресурсы одного mysql сервера на несколько пользователей равномерно - не возможно ввиду полного отсутствия такого механизма - отсюда и пошли плодиться различный vps-ы вирт серверы и тд - проблема в том что для самой организации вирт сервера нужно ресурсов гораздо больше чем стоит обычный shared хостинг.
По этому все таки для общественной CMS все что можно вынести из базы - надо вынести.
Насчет блоков - согласен - надо думать когда их делать как кешировать, но если и их части будут браться с диска уже сгенерированных частей ноды - то это лучше чем из базы.
Ps drupal.ru тормозит при добавлении комментария - 12 секунд - это нормально?
например, зачем в node_images загружаются все изображения прикрепленные к ноде, когда в тизере используется только 1-2 из них
Но на этапе загрузки ноды она не знает, в каком контексте она будет выводиться
некоторое время назад в cck появилась настройка display fields, в которой задаётся какие поля показывать в тизере какие нет.. может быть я немножко не понимаю о чём говорю, но чисто визуально заметил ,что при правильной настройке, страница со списком сложных галерей(выполненных одной нодой с кучей картинок загруженных через имаджфилдов) такого плана - http://clubwave.ru/gallery стала генерироваться намного быстрей
По этому все таки для общественной CMS все что можно вынести из базы - надо вынести. объясните откуда такое незыблемое мнение? Желательно на примерах общественных CMS
drupal.ru тормозит при добавлении комментария - 12 секунд - это нормально? а что тут не нормального? владельцу сайта так удобней..
Еще раз повторю, что в разных местах сайта требуются разные части ноды и порой views намного эффективнее выберет необходимую порцию данных, нежели сбор разнородных данных с диска, даже с применением sqlite
Не понимаю, где node_load отжирает память? стартовая страница - 10 нод грузятся в цикле, сколько они могут отожрать?
Про cck речи я не вел, а про стандартный вывод - например, таксономия или стартовая страница.
Node_images - это такой модуль, никакого отношения к cck не имеющий.
Именно в определении, например через display fields (лично не пробовал) или собственноручно и можно оптимизировать количство завпросов к базе и количество попадаемой в память информации - этот вопрос очень актуально стоит перед всеми кодерами на drupal.
Научить views строить эффективные запросы к базе по любым кликам мыши - нереально! Подавляющее большинство разработчиков вообще не представляют схемы базы данных, а те кто представляют могут написать сами оптимизированный запрос и добавить нужные индексы, собственно как и изменить порядок CCK полей для вывода, дабы не тянуть ненужное и не связывать левые таблицы!
столкнулся с тем что на одном хостинге друпал не работал потому что стояло memory_limit 8мб, а другие CMS и даже электронный магазин с огромным перечнем товаров работал довольно шустро несколько лет и не тормозил
На самых минимальных тарифах VPS дают 32 мега оперативки... Этого хватает для php + apache + mysql. Memory limit легко устанавливается в 16, при запросе - выделяется память, после запроса - она освобождается и отдается, если нужно, под другие процессы.
Я про shared молчу, там оперативка ваще гигами измеряется.
даже электронный магазин с огромным перечнем
Там была модульность, таксономия, локализация через БД ?
О, какая интересная дискуссия , без иронии
В аське не появляюсь - на работе закрыто, а дома, а дома - дочь вчера родилась
andypost@drupal.org, не понимаю как можно воспринимать друпал без cck.. уменя только один примитивнейший сайт есть в таком виде http://stupidnews.ru
image модуль вообще хлам, я им пользовался однажды, на заре пятой части дурпала.. тогда я только начинал в друпале немного шарить..
views мне не кажется, что отжирает много ресурсов.. он того стоит, без него друпал тоже ничто грубо говоря..
kiev1, ну это вообще.. где вы такой антиквариат видели? у меня на друпале магазин работает без кэша на шареде и мемори лимит через .htaccess выставлен 64 мб.. хостинг копейки стоит по сравнению с любой впс.. Да нужно сразу осознавать, что друпал с кучей модулей намного требовательней других cms, зачем ставить хайтековский продукт на допотопное железо?
Valeratal, круто, поздравляю с дочкой
да дискуссия интересная, особенно для русского сайта..
clubwave.ru, drupal можно и нужно воспринимать без cck + views - он ко всему в придачу еще и CMF!
Например: для написания интерфесов к сторонней базе данных, или как web-service, или для быстрой разработки xml-rpc связок.
На семенаре попробую продемонстрировать первый из вариантов.
нет я друпал без коддинга использую.. так проще с кучей сайтов работать
в друпале даже не кешируется RSS ((( в джумле и то RSS берется из дискового кеша
А какой смысл кешировать RSS ? особенно если материалы часто меняются (например кол-во коментариев)?
С другой стороны что Вам мешает написать под свою конкретную задачу модуль перекрывающий вывод rss со своим "мудрым" кешированием?
а джумла отсосная
в смысле отстойная? ну да, вот по этому я и пишу пример что даже в ней и то кеширование RSS есть в виде файлов, а у нас спорят что файлы не быстрее mysql.
зачем самому писать? если кеширование нужно 99 процентам пользователей, то почему его нет?
kiev1, всмысле отсосная!
а причём тут кэширование рсс вообще?
я активный пользователь системы. разработал не один 10-к сайтов и ниразу не пользовался рсс равно как и ни разу не заморачивался вопросом какой кэш быстрей..
друпал сделан для удобства разработчиков.. хотите готовое производительное решение берите datalife.. не забудьте шапочку перерисовать
кстати, бд быстрей файлов.. она и создана для того, чтобы хранить информацию.. то что она перегружена вопрос другой.. друпаллеры - идеалисты и это правильно!
с какой такой радости myisam таблицы mysql в данной реализации друпала быстрее файловой системы? myisam например вообще напрочь блокирует доступ к таблице на чтение в то время когда в нее производится запись, а в таблицу сессий запись производится при любом запросе контента - получается замкнутый круг - на сервере нарастает очередь к базе, потом нарастает количество коннектов, процессов nginx/apache и все виснет. посмотрите на нагрузку обычного сервера - друпал очень сильно работает с php, однако вешается в основном база. При чем самое обидное - все виснет не от посетителей а от банальных поисковиков которые обходят сайт.
Базы данных быстрее файловых систем в плане выборки данных практически всегда, за исключением одного случая:
Данные из файла "как есть" автоматически пересылаются клиенту через низкоуровневой сервис типа nginx. Только в этом случае файловая система обычно быстрее БД на обычных задачах.
Про массовые операции иначе: там впереди специальные БД типа map-reduce... Но не файловая система, естественно.
P.S.: причина в специализации и кэшировании со знанием структуры данных...
подождите, так вы хотите сессии вынести на файлы?
у меня не глубокие познания в этой области, но я знаю, что бд работает быстрей текстовых файлов..
кстати, насчёт типов таблиц, что всётаки решим, можно безболезненно поменять?
На 5ке особого прироста не заметил, но и очень нагруженных проектов нет
Реально имеет смысл только для таблиц которые не перечислены в sequences - все остальние полюбому при добавлении записи лочатся целиком
Тема уже не раз поднималась на форуме, вердикт окончательно не вынесен!
ИМХО innodb немного замедлит чтение и использовать его стоит только для кеша, были еще пожелания для коментов и sequences
Я поменял "на лету", на живом сайте. Две недели прошло, полет нормальный. Заодно перевел на InnoDB все таблицы кешей, node и node_revisions, и еще кое-какие, чисто для эксперимента. Белые экраны и жесткие тормоза практически пропали - ни разу не видел, хотя до этого часто было, особенно в админке, при работе с блоками и модулями, их много у меня. И да, сайт начал отзываться чуть быстрее - это конечно на глаз, я не такой суперспец, да и SSH нет
Переводил через PHPMyAdmin, в закладке Operations каждой таблицы.
p.s. A MyISAM, скорее всего, стоИт по умолчанию в инсталляторе Друпала, так как не у всех хостеров может быть поддержка InnoDB - по крайней мере, есть такие сведения о некоторых российских хостерах. Т.е. те, кто в теме, и сами переведут свои таблицы на InnoDB, если им это нужно, а для чайников и просто занятых по умолчанию стоит тип таблиц, который есть на всех хостингах с MySQL.
Akzhan - конечно идеологически базы данных и сделаны для оптимизации управления данными, но в данном контексте - согласитесь - держать таблицу сессий в таком типе таблиц которая блокирует все чтение при записи - это совсем не умно, правда? Да и если б база была быстрее - то и картинки там бы хранили...
нет - сессии выносить в файлы как раз не надо, наоборот, но для них надо применять хотя бы inno-db тип данных. А вынести из базы надо контент, ну хотя бы поля ноды - надо переписать node_load что бы он брал данные с дискового кеша.
Для сессий самое оптимально - размещать их в памяти (memcache, apc)
в Этом отношении есть очень интересны иперспективный модуль Cache Router
спасибо, а там для 5-й версии его самого своим-же патчем патчить надо? или я что то не до понял
andypost@drupal.org, полнятно, что всё нужно проверять в реальных условиях.. у меня больше вопрос можно ли безболезненно поменять тип таблицы? с удовольствием проверю, если можно..
kiev1, мне кажется всё это лишний геморой для разработчика самого друпала и для разработчика сайта на самом друпале.. как вспосню на сколько папок в джумле нужно поставить права.. лучше сервер понастраивать
marazmus, перечислите, пожалуйтса, все таблицы, которые на ваш взгляд стоит перевестим в inno-db, завтра потестю
Те, которые, имхо, лочатся на уровне таблицы, и те, крэш которых крайне неприятен, но случается:
blocks
cache*
menu
node
node_revisions
search*
sequences
sessions
system
users
variable
watchdog
крэш только у кэша и поиска бывает?
На них почти не было, в основном падала таблица сессий.
А кэш и поиск перевел из-за lock table на запись - таблички-то жирные.
у меня перестали крешатся таблицы, после увеличения оперативной памяти
ведь креши - от нехватки
marazmus, можно пояснить эту фразу?
А кэш и поиск перевел из-за lock table на запись - таблички-то жирные.
у меня крэшился кэш и както раз комментс и да из-за нехватки памяти..
так что значят звёздочки?
Звездочки - то есть все таблички имя которых начинается с cache
ааа
интересно куда всё-таки автор делся?
Радует, что производительность серверов растет быстрее, чем drupal тяжелеет. Поэтому будущее у него радужное. Лет через пять проблемы загруженности будут возникать скорее всего только на shared hosting.
Подтверждаю, на подтормаживающем (а временами и сильно тормозящем) сайте после перевода таблиц cache_* и sessions в innoDB стало заметно быстрее. Нет, конечно, летать не стало, но стало явно быстрее и перестало "затыкаться". Спасибо огромное за наводку.
PS: Однако, справедливости ради надо сказать, что установка модуля Cacherouter и применение в нём кэширования на файлах даёт значительно больший результат. Но модуль этот сыроват ещё немного...
Уважаемые знатоки, а подскажите, пожалуйста, можно ли как-то уговорить таблицу node_revisions сконвертироваться в innoDB, если phpMyAdmin при попытке конвертирования выдаёт такую ошибку:
node_revisions не нужно делать типа innoDB, нужно только те блокировка которых критична
Ага, спасибо. Просто в списке marazmus'a чуть выше она была, как раз...
Подскажите, пжл, а имеет ли смысл переводить таблицы locales_* в InnoDB ? Посмотрел - там очень много (тысячи) записей.
переводить надо только те таблицы в которые происходит запись данных во время любого обращения к сайту - то есть один посетитель запросил страничку, таблица в myisam заблокировалась и в течении того времени пока он ее не получит - все остальные висят
Ага, уже проясняется, спасибо!
установите модуль devel он показывает какие таблицы лочатся при обращении к сайту
Проблема в Drupal не в его производительности, а в его оптимизации. Правильно настроенное кэширование очень помогает. Я имею ввиду не только стандартное кэширование Drupal, но и кэширование Panels, Views, кэширование в памяти сервера и т.д.
Так же необходимо оптимизировать страницы сайты по наполнению. Необходимо понимать, что если на страницу выводить 10 блоков в которых описаны последние новости 10 разделов сайта, 5 блоков по 10 последних новостей и 5 рекламных блоков. То кэширование будет очень сложное (стандартными средствами Drupal) и сервер VDS за 700 рублей может не потянуть 10 000 уникальных пользователей в день будь даже CMS написана "профессионалами" на C++. А Вы уверены что эти "профессионалы" - не ламеры "из Индии". Пообщавшись с одним программистом из одной очень популярной в России CMS (платной), я начал сомневаться что они не "из Индии", после гордо сказанной фразы - "я HTML незнаю, я PHP программист!!".
Например как решить предыдущий пример при этом стараясь несильно замедлить скорость загрузки страницы и при этом разгрузить сервер. 10 разделов сайта - это 10 подсайтов. Все блоки центральной страницы это iframe, отдаются с gzip сжатием в ajax блоки с 10 подсайтов. Надо понимать что информации на главную страницу отдается много и загружаться очень быстро - она никогда не будет. Iframe - позволяют перевисти большую часть страницы в статику которую можно хорошо закэшировать. Так же придётся поработать с некоторыми блоками на уровне PHP кода и шаблонов тем оформления. Т.е. вывод блока имени пользователя и блока добавления поля комментирования производится в шаблоне (в нём выставляются метки - выводить или нет и там же запрашивается имя пользователя через стандартные процедуры Drupal). В итоге вы получаете 10 сайтов объединенных в 1 портал, понятно, что тут 1 VDS за 700 рублей может не потянуть :).
На большой проект часть кода PHP в виде модулей или просто кода придётся писать Всё равно вне зависимости от CMS, так же как и аудит кода на безопасность и производительность придётся проводить вне зависимости от CMS.
Ну и самое главное генерация страниц - она всегда тяжела и если вы хотите генерировать очень много контента на сайте при большой посещаемости, то ваш выбор - покупка сервера. Стоят они недорого и в современных серверах можно иметь до 32 гигабайт памяти и больше. Просто ненужно сразу смотреть на сервер с 4 xeon-ами от IBM с 32 гигабайт памяти за 150 000 и более, хватит и за 25 000 на покупку + 10 000 на модинг. Для проекта с посящаемостью в 50 000 уникальных пользователей в день это немного.
Или Вы действительно думаете что одноклассники работают на 1 сервере и все их 10 000 000 пользователей ходят каждый день, а не раз в 10 дней (10 000 000 / 10 = 1 000 000 в день / 50 000 на сервер = 20 серверов * 35 000 руб = 700 000 руб = Сквозное размещение 728x90, 240x400 Пакет «Москва», недельный 15 млн. показов/нед. охват - 2 300К человек на одноклассниках (с количеством серверов я конечно утрирую, но всё же...))? Может у вас закралась ошибка при подсчете окупаемости проекта? Ведь даше некоммерческие проекты - это всеголишь бизнес который своей целью не ставит получение прибыли и он не обязатльно должен существовать на внешние средства.
перевел часть таблиц в innoDB
Наблюдаю глюк, не могу отредактировать теги у нод
а именно:
не работает автозаполнение - то есть кружок крутиться, но варианты не выпадают.
А при нажатии добавить (опубликовать) ошибка ява-скриптов и все, страница останавливается
Подскажите, где хряняться метки, в какой таблице
ошибка была не из-за InnoDB
Вот вопрос, как devel-ом определить, какие таблицы лочаться?
Подписываюсь.
Господа, поверьте - если бы InnoDB было бы панацеей, то нужные таблицы создавались бы этого типа во время установки (проверить поддержку InnoDB хостингом на этапе инсталяции - раз плюнуть), или, как минимум, это было бы описано в install.txt.
Насчёт сессий и анонимных пользователей посмотрите этот модуль: [module=no_anon]
Кстати, насчет innodb - это будет обязательным в 7ке! готовимся
спасибо
надо попробовать
отвратительное решение
InnoDB?
а почему? есть не везде?
потому что без тюнинга именно под сервер+сайт это в принципе те же яйца.
а на впс своём и так что нужно можно сделать
+да, есть не везде
а чем делали этот график, это до и после включения модуля no_anon
мунин
если кому надо есть эта версия для 4.11. запрос в личку