22 сентября 2011 в 14:24
Пока что не сталкивался с действительно высоконагруженными проектами, но понимание нужно, да и расти надо бы в профессиональном плане. Так что, задался я вопросом....
Вообщем то вопрос простой. Расскажите как друпал дружит с трафиком, нагрузкой итд. Как лучьше оптимизировать. Поделитесь опытом и накидайте ссылок почитать, если не сложно.
Основные вопросы пока что такие:
1. Как прикинуть или проверить какой трафик выдержит сайт на друпале (понятно дело, что сайты бывают разные, поэтому куда смотреть и что сравнивать)
2. Что посоветуете сделать для улучьшения (модули, настройка кеширования итд) со стороны сайта, так как хостюсь на патроле и соответственно сервак отстроить под проект не смогу, да и не умею.
3. При каких нагрузках стоит начинать задумываться о выделеном сервере на что обращать внимание.
4. Что еще забыл вписать в список вопросов?
Вообщем буду признателен за любую целевую информацию и особенно за реальные примеры из жизни. По принципц "мой сайт держит 10 000 уников в сутки, стаивл это это и разместил там то"
Комментарии
Рекомендую видео курс от лулабот на тему оптимизации.
Можно еще посмотреть как ребята из Forbes делают это.
1. Siege, apache bench и.т.п.
2. Всё что можно закешировать, нужно закешировать. Всё что не нужно, нужно отключить. Использовать профилирование, смотреть запросы и.т.п. Более подробно можно советовать только в конкретном случае.
3. Это настолько зависит от сайта, что надо смотреть по результатам п.1.
4. Вам виднее.
[Lullabot.com] Drupal Performance & Scalability
Больше спасибо.
Правда в очередной раз уприраюсь в плохое знание английского. Так что за русские мануалы и уроки буду так же очень признателен.
Думаю всеж стоит для общего развития посмотреть основы основ, в том числе и по серверам и по запросам. Накидайте пожалуйста ссылок и на "песочницу" по вопросу.
Осталось только найти веремя на изучени вопроса...
Вопросы производительности решаются обычно одним из следующих способов:
Насколько я понял у вас еще нет ни высоконагруженного проекта, ни опыта, ни знания английского языка. Вы уверены, что эта информация необходима вам именно сейчас? Может стоит сначала сделать сайт с хорошей посещаемостью, а проблемы решать по мере их поступления?
Нет, чувак, надо именно сейчас переписывать вьюс, отказываться от панелей, настраивать сервер, хакать ядро + ещё овер9000 способов.
+ оптимизировать admin menu
Точно, забыл про него, 20 НЕКЕШИРУЕМЫХ ЗАПРОСОВ
по теме, видео с украинского кэмпа можно глянуть
доклад Артема Панькова
(вообще видео с кэмпов смотреть полезно, если уж не присутствовать)
>Вы уверены, что эта информация необходима вам именно сейчас?
Естественно. Я ее собираю для собственного развития, в первую очредь.
>Точно, забыл про него, 20 НЕКЕШИРУЕМЫХ ЗАПРОСОВ
Поподробнее можно?
Присоединяйся к секте http://www.drupal.ru/node/44843
Синкора вот ещё куда-то пропал...
Первое - по отношению к хостингу/серваку:
главное - правильно настроить сервак или выбрать хостинг, если сервак не свой под рукой.
на сервере, в качестве бекенда можно использовать ngnix, что снизит нагрузку на апач, который очень часто и служит основной нагрузкой на веб сервер. Также нужно хорошее быстродействие mysqld. Включение кеширование в мускуле запросов и APC для PHP. Также нужно, по возможности увеличить память для пхп - файл php.ini, .htaccess, или другие конф. файлы, в зависимости от настроек сервака
теперь по друпалу.
Включаем кеширование статики, и выставляем минимальное время жизни кеша в соответствии с нагрузкой на сайт.
Настраиваем крон, чтоб запускался, а то всякое бывает)
Отключаем все неиспользуемые модули
Стараемся по минимуму использовать флеши картинки не оптимизированные и другое - все что может потянуть много траффика и ресурсов
Если все туго, то можно пробовать альтернативное кеширование настроить на друпале
В основном корень всех проблем - хостинг, там нужно копать. Смотреть где тормоза - мускул или веб сервак, и соответственно оптимизировать. По дефалту что апач, что мускул не оптимально отстроены. а поиск всех .htacess в каждой дире вообще заметно снижают производительность апача
это так. если в двух словах.
Вообще-то в этом случае бекэндом будет как раз апач. К тому же, на самом деле, в этом случае апач вообще не нужен. Nginx замечательно работает с php с помощью FastCGI.
Сервер конечно важно хорошо настроить, но для нагруженного проекта придётся больше возиться с самим друпалом.
В частности стоит посмотреть на PressFlow.
это да, за бекенд загнул) nginx на передовую
>Включаем кеширование статики, и выставляем минимальное время жизни кеша в соответствии с нагрузкой на сайт.
Отсюда можно поподробнее? Что смотреть, куда думать?
кеш позволяет не генерировать каждый раз динамически страницу, а сохранить сгенерированную копию в таблице кеша, и потом, когда юзер открывает просматривает страницу ему отдается сохраненная копия страницы, взятая с БД. Выигрыш - не нужно каждый раз вызывать функции для формирования страницы, снижается нагрузка на сервер. Ощутимое снижение нагружки наблюдается тогда, когда информация на странице модифицируется не часто, так как частое изменение информации может повлечь за собой частую перестройку кеша, что будет тянуть все теже ресурсы.
смотреть в настройках производительности. там есть пункт кеширование, вот его включить. минимальное время жизни кеша - минимальное время сколько будет жить кеш до пересоздания при изменении материала (фактически сколько времени пользователи будут видеть неизмененный материал на странице при ее изменении)
если информация изменяется редко, то время жизни можно поставить больше, если часто изменяется - то меньше, чтобы пользователи быстрее увидели обновленный контент. Компрессию можно выключить друпалом - каналы широкие сейчас инета, а нагрузки будет поменьше на сервак. только после выключения компрессии и включенном кеше нужно очистить кеш, так как юзеры увидят иероглифы вместо сайта.
Неразумно отключать компрессию... Оверхед небольшой, т.к. сжимается только при попадании в кеш, а канал экономится.
Полезно также агригировать и сжимать css и js.
та с текущими каналами, не думаю что это сильно разгрузит его, а учитывая что большинство хостеров дают памяти минимум оперативной, то каждый сэкономленный метр ценен. поэтому, думаю, что работать быстрее будет когда больше канала зальет трафик, чем когда в память упрется
за агрегирование css и js - да, но только если уже закончили изменять css, так как если его правите, то тогда возможны косяки в виде недоступности css файла ранее агрегированного