Трафик, нагрузка и прочее... Расскажите..

Главные вкладки

Аватар пользователя S_F S_F 22 сентября 2011 в 14:24

Пока что не сталкивался с действительно высоконагруженными проектами, но понимание нужно, да и расти надо бы в профессиональном плане. Так что, задался я вопросом....
Вообщем то вопрос простой. Расскажите как друпал дружит с трафиком, нагрузкой итд. Как лучьше оптимизировать. Поделитесь опытом и накидайте ссылок почитать, если не сложно.

Основные вопросы пока что такие:
1. Как прикинуть или проверить какой трафик выдержит сайт на друпале (понятно дело, что сайты бывают разные, поэтому куда смотреть и что сравнивать)
2. Что посоветуете сделать для улучьшения (модули, настройка кеширования итд) со стороны сайта, так как хостюсь на патроле и соответственно сервак отстроить под проект не смогу, да и не умею.
3. При каких нагрузках стоит начинать задумываться о выделеном сервере на что обращать внимание.
4. Что еще забыл вписать в список вопросов?

Вообщем буду признателен за любую целевую информацию и особенно за реальные примеры из жизни. По принципц "мой сайт держит 10 000 уников в сутки, стаивл это это и разместил там то"

Комментарии

Аватар пользователя bsyomov bsyomov 22 сентября 2011 в 20:42

1. Siege, apache bench и.т.п.
2. Всё что можно закешировать, нужно закешировать. Всё что не нужно, нужно отключить. Использовать профилирование, смотреть запросы и.т.п. Более подробно можно советовать только в конкретном случае.
3. Это настолько зависит от сайта, что надо смотреть по результатам п.1.
4. Вам виднее. Smile

Аватар пользователя S_F S_F 22 сентября 2011 в 21:50

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

Аватар пользователя Alex Bacart Alex Bacart 22 сентября 2011 в 22:01

Вопросы производительности решаются обычно одним из следующих способов:

  1. Разработчик заранее, еще до написания хоть одной строки кода проектирует систему и планирует что и как в ней будет реализовано. Решения принимает исходя из личного опыта. Не ваш случай ИМХО.
  2. Сначала делается проект, привлекаются посетители, возникают проблемы с производительностью, проблемы решаются.

Насколько я понял у вас еще нет ни высоконагруженного проекта, ни опыта, ни знания английского языка. Вы уверены, что эта информация необходима вам именно сейчас? Может стоит сначала сделать сайт с хорошей посещаемостью, а проблемы решать по мере их поступления?

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 22 сентября 2011 в 22:54

"Vydrin_AP" wrote:
Может стоит сначала сделать сайт с хорошей посещаемостью, а проблемы решать по мере их поступления?


Нет, чувак, надо именно сейчас переписывать вьюс, отказываться от панелей, настраивать сервер, хакать ядро + ещё овер9000 способов.

Аватар пользователя Valeratal Valeratal 23 сентября 2011 в 9:57

по теме, видео с украинского кэмпа можно глянуть
доклад Артема Панькова

(вообще видео с кэмпов смотреть полезно, если уж не присутствовать)

Аватар пользователя S_F S_F 23 сентября 2011 в 12:06

>Вы уверены, что эта информация необходима вам именно сейчас?
Естественно. Я ее собираю для собственного развития, в первую очредь.

>Точно, забыл про него, 20 НЕКЕШИРУЕМЫХ ЗАПРОСОВ
Поподробнее можно?

Аватар пользователя fantom84 fantom84 26 сентября 2011 в 21:03

Первое - по отношению к хостингу/серваку:
главное - правильно настроить сервак или выбрать хостинг, если сервак не свой под рукой.
на сервере, в качестве бекенда можно использовать ngnix, что снизит нагрузку на апач, который очень часто и служит основной нагрузкой на веб сервер. Также нужно хорошее быстродействие mysqld. Включение кеширование в мускуле запросов и APC для PHP. Также нужно, по возможности увеличить память для пхп - файл php.ini, .htaccess, или другие конф. файлы, в зависимости от настроек сервака

теперь по друпалу.
Включаем кеширование статики, и выставляем минимальное время жизни кеша в соответствии с нагрузкой на сайт.
Настраиваем крон, чтоб запускался, а то всякое бывает)
Отключаем все неиспользуемые модули
Стараемся по минимуму использовать флеши картинки не оптимизированные и другое - все что может потянуть много траффика и ресурсов
Если все туго, то можно пробовать альтернативное кеширование настроить на друпале

В основном корень всех проблем - хостинг, там нужно копать. Смотреть где тормоза - мускул или веб сервак, и соответственно оптимизировать. По дефалту что апач, что мускул не оптимально отстроены. а поиск всех .htacess в каждой дире вообще заметно снижают производительность апача

это так. если в двух словах.

Аватар пользователя bsyomov bsyomov 26 сентября 2011 в 22:47

"fantom84" wrote:
качестве бекенда можно использовать ngnix, что снизит нагрузку на апач

Вообще-то в этом случае бекэндом будет как раз апач. К тому же, на самом деле, в этом случае апач вообще не нужен. Nginx замечательно работает с php с помощью FastCGI.
Сервер конечно важно хорошо настроить, но для нагруженного проекта придётся больше возиться с самим друпалом. Smile
В частности стоит посмотреть на PressFlow.

Аватар пользователя fantom84 fantom84 26 сентября 2011 в 23:17

bsyomov wrote:
"fantom84" wrote:
качестве бекенда можно использовать ngnix, что снизит нагрузку на апач

Вообще-то в этом случае бекэндом будет как раз апач. К тому же, на самом деле, в этом случае апач вообще не нужен. Nginx замечательно работает с php с помощью FastCGI.
Сервер конечно важно хорошо настроить, но для нагруженного проекта придётся больше возиться с самим друпалом. Smile
В частности стоит посмотреть на PressFlow.

это да, за бекенд загнул) nginx на передовую

Аватар пользователя S_F S_F 28 сентября 2011 в 16:28

>Включаем кеширование статики, и выставляем минимальное время жизни кеша в соответствии с нагрузкой на сайт.

Отсюда можно поподробнее? Что смотреть, куда думать?

Аватар пользователя fantom84 fantom84 28 сентября 2011 в 18:24

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

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

Аватар пользователя bsyomov bsyomov 28 сентября 2011 в 19:57

Неразумно отключать компрессию... Оверхед небольшой, т.к. сжимается только при попадании в кеш, а канал экономится.
Полезно также агригировать и сжимать css и js.

Аватар пользователя fantom84 fantom84 28 сентября 2011 в 21:44

та с текущими каналами, не думаю что это сильно разгрузит его, а учитывая что большинство хостеров дают памяти минимум оперативной, то каждый сэкономленный метр ценен. поэтому, думаю, что работать быстрее будет когда больше канала зальет трафик, чем когда в память упрется
за агрегирование css и js - да, но только если уже закончили изменять css, так как если его правите, то тогда возможны косяки в виде недоступности css файла ранее агрегированного