Как рассчитать мощность сервера?
Сейчас ищу сервер для себя. Есть сайты на вордпрессах с суммарной посещаемостью 40 000 в сутки. Бегет виртуальный сервер загружен на 766 cp. Сайты с кешированием total cache w3.
Какой сервак искать. Проц, память, винт, трафик. Вообще нуб в этих вопросах я. Трафик в основном из России.
Так как у Beget СР — это «попугаи» и эта величина зависит от процессора, а также от того, за какой период load avarage считается и как при вычислении каждого CP, то ответить на Ваш вопрос исходя из указанной нагрузки нельзя. Так как она не указана.
Из опыта — для подобной посещаемости на Word Press в случае их оптимизации и перегруженности достаточно было процессора Е3-1230, 16GB RAM, SSD, соответственно я бы взял виртуальный сервер с выделенными накопителями (лучше выделенного Е3-1230, 16GB RAM, SSD в данном случае):
VPS (KVM) — E5-2650 v4 (12 Cores) 20GB DDR4 2 х 240GB RAID1 SSD 1Gbps 20TB
VPS (KVM) — E5-2650 v4 (24 Cores) 40GB DDR4 4 x 240GB RAID10 SSD 1Gbps 40TB
Чтоб наверняка. Так как при такой посещаемости трафик может быть в пределах 15-20ТБ. Но опять же, не зная, что за сайты, сложно сказать на 100% что конкретно для Вас будет лучше.
На счет типа накопителей — порекомендовал бы Вам однозначно вариант с SSD, потому как WP имеет нехорошее свойство создавать значительную нагрузку в IOPS.
Расчет нагрузки
Интересуют примеры из конкурсной документации, где приводятся подобные обоснования и расчеты.
Re: Расчет нагрузки
>где приводятся подобные обоснования и расчеты.
а ты типа не инженер и расчёт делать не умеешь?
Re: Расчет нагрузки
> а ты типа не инженер и расчёт делать не умеешь?
Это нарушение правил форума и переход на личности.
Если ты умеешь, научи других, может пореже на СШГЭС будет автоматика не срабатывать.
Re: Расчет нагрузки
>Это нарушение правил форума и переход на личности.
Всегда удивлялся тупости фразы "переход на личности". Как будто бы этот топик — это божественное знамение, а не результат деятельности конкретной личности Арсена Шнуркова, который сломал автоматику на СШГЭС.
Re: Расчет нагрузки
ну как минимум 2 Гб памяти и 2 x Opteron 242. Ибо JIRA
Re: Расчет нагрузки
Для 128. По тупенькому
Менее тупенькое сам придумаешь. Дальше смотришь по top сильно ли загибается «сервер» и экстраполяцией выходишь на требующиеся параметры.
Как рассчитать нагрузку на сервер
Методология расчета нагрузки, количества пользователей информационной системы — web-сайта или сервиса
При разработке/создании web-сайта, мобильного приложения, WEB-сервиса – иными словами Информационной системы (ИС) встает вопрос о требующих аппаратных ресурсах – количестве серверов (виртуальных машин).
Приведённая методика описывает расчет количества пользователей и «оборудования» для территории Российская федерация.
Исходные данные
- Веб сайт «Визитка»;
- WEB-сервис для мобильных приложений, работающий по протоколу http/https, взаимодействующий с Базой данных;
- База данных SQL (NOSQL);
- WEB-клиент – реализующий функционал мобильного приложения для web пользователей, также взаимодействующий с Базой данных.
- Пик с 8 часов локального времени нарастание до 70% в течении часа;
- Снижение нагрузки до 18 часов до уровня 50%;
- Снижение нагрузки до 22 часов до уровня 10%;
- Снижение нагрузки до 00 часов до уровня 5% до утреннего пика.
Приступим к расчету
Базовые показатели – численность населения, по данным Росстат «По данным Росстата «Численность населения Российской Федерации по муниципальным образованиям на 1 января 2012 года, тыс человек», отсюда и далее на Росстат. Нормализуем, убираем дубли и вхождения, добавляем к таблице часовой пояс в соответствии с ПП (постановлением правительства) № 725 от 31 августа 2011 г. или в WiKi – Часовые пояса России.
Результирующая таблица (здесь и далее рисунки из файла Excel – оригинальный файл доступен на GoogleDoc). 
и далее – не будем загромождать статью.
Результатом данных распределения является Сводная таблица (Pivot table)
кстати, обратите внимание, неожиданный(по крайней мере для меня) результат – 101 миллион человек живет… по московскому времени.
Следующая, рабочая таблица (фрагмент) 
- Напрямую задаваемая численность пользователей Системы (при этом коэффициент наши пользователи 100%)
- Численность целевой группы (к примеру 22 миллиона домохозяйств России) и процент их охвата в колонке «наши пользователи»
Для системы описанной в примере итоговый результат выглядит так: 
Понятно что Система создана совсем простая как и профиль пользователя простейший – осуществляющим простые операции.
Так же нужно иметь в виду и уметь пользоваться при прогнозах аналитическими отчетами к примеру – ОТРАСЛЕВОЙ ДОКЛАД. Федеральное агентство по печати и массовым коммуникациям Интернет в России Состояние, тенденции и перспективы развития.
или
Мобильный интернет России.
Интересно было смоделировать расчетную модель на более сложном профиле пользователя и системе – улучшить методику.
Русские Блоги
[Введение] Алгоритм динамической балансировки нагрузки с обратной связью используется для учета нагрузки и отклика сервера в режиме реального времени, а пропорция запросов, обрабатываемых между серверами, постоянно корректируется, чтобы избежать того, что некоторые серверы по-прежнему получают большое количество запросов при перегрузке, тем самым улучшая пропускную способность всей системы.
Алгоритм динамической балансировки нагрузки с обратной связью учитывает нагрузку и отклик сервера в режиме реального времени и постоянно регулирует соотношение обработки запросов между серверами, чтобы избежать того, что некоторые серверы по-прежнему получают большое количество запросов при перегрузке, тем самым улучшая пропускную способность всей системы. На рисунке 1 показана рабочая среда алгоритма, в котором запущен процесс Monitor Daemon в планировщике загрузки и Monitor Daemon для мониторинга и сбора информации о нагрузке каждого сервера. Monitor Daemon может рассчитать комплексное значение нагрузки на основе информации о множественной нагрузке. Monitor Daemon вычисляет набор новых весовых коэффициентов на основе суммарного значения нагрузки каждого сервера и текущего веса.Если разница между новым весом и текущим весом превышает установленное пороговое значение, Monitor Daemon устанавливает вес сервера для ядра. В планировании IPVS планирование соединений в ядре обычно использует алгоритм взвешенного циклического планирования или алгоритм взвешенного минимального планирования соединений.
 |
Рисунок 1: Рабочая среда алгоритма динамического распределения нагрузки с обратной связью
Планирование соединения
Когда клиент получает доступ к сети через TCP-соединение, время, необходимое для обслуживания, и потребляемые вычислительные ресурсы сильно различаются и зависят от многих факторов. Например, это зависит от типа запрашиваемой услуги, текущей пропускной способности сети и текущего использования ресурсов сервера. Для некоторых запросов с высокой нагрузкой требуются вычислительные запросы, доступ к базе данных и потоки данных с длинным ответом, а для запросов с более низкой нагрузкой часто требуется только чтение страницы HTML или выполнение простых вычислений.
Изменения во времени обработки запроса могут привести к перекосу в использовании сервера, то есть к несбалансированной нагрузке между серверами. Например, есть веб-страница с файлами A, B, C и D, где D — это большой файл изображения, и браузер должен установить четыре соединения для извлечения этих файлов. Когда несколько пользователей одновременно получают доступ к странице через браузер, наиболее экстремальным случаем является то, что все запросы D-файла отправляются на один и тот же сервер. Таким образом, может возникнуть такая ситуация, некоторые серверы были перегружены, в то время как другие серверы в основном простаивают. В то же время некоторые серверы слишком заняты, имеют длинную очередь запросов и продолжают получать новые запросы. И наоборот, это заставит клиентов долго ждать и чувствовать, что качество обслуживания системы низкое.
Простое планирование соединения
Простое планирование соединения может вызвать наклон сервера. В приведенном выше примере, если используется алгоритм циклического планирования и в кластере ровно четыре сервера, один сервер всегда должен получать запросы на D-файлы. Эта стратегия планирования приведет к низкому использованию всех системных ресурсов, поскольку некоторые ресурсы исчерпаны, что заставляет клиентов долго ждать, пока другие ресурсы простаивают.
Характеристики фактического трафика TCP / IP
Литература показывает, что сетевой трафик происходит в виде волны. После длительного периода небольшого трафика будет период доступа к большому трафику, за которым следует небольшой трафик, который периодически возникает как волны. В литературе показано, что в сети WAN и LAN существует самоподобие сетевого трафика, а также поток самоподобия в потоке веб-доступа. Это требует механизма динамической обратной связи, использующего состояние группы серверов для решения проблемы самоподобия потока доступа.
Механизм динамической балансировки нагрузки с обратной связью
Характеристики трафика TCP / IP в разговорной речи говорят о том, что существует много коротких транзакций и некоторые длинные транзакции, а рабочая нагрузка длинных транзакций занимает относительно высокую долю всей рабочей нагрузки. Поэтому мы должны разработать алгоритм балансировки нагрузки, чтобы избежать того, что длинные запросы транзакций всегда распределяются на некоторые машины, но делить распределение с заусенцами на относительно равномерное распределение, насколько это возможно.
Мы предлагаем механизм динамической балансировки нагрузки с обратной связью для управления распределением новых соединений и, таким образом, для контроля загрузки каждого сервера. Например, алгоритм взвешенного циклического планирования используется в ядре планировщика IPVS для планирования новых соединений с запросами, демон мониторинга запускается в пользовательском пространстве планировщика загрузки. Monitor Daemon регулярно отслеживает и собирает информацию о нагрузке каждого сервера, а также рассчитывает полное значение нагрузки на основе информации о множественной нагрузке. Monitor Daemon рассчитывает новый набор весов на основе суммарного значения нагрузки и текущего веса каждого сервера. Когда значение интегрированной нагрузки показывает, что сервер занят, вновь рассчитанный вес будет меньше его текущего веса, поэтому количество вновь распределенных запросов к серверу будет меньше. Когда значение полной нагрузки указывает на низкую загрузку сервера, вновь рассчитанный вес будет больше его текущего веса, чтобы увеличить количество вновь распределенных запросов к серверу. Если разница между новым весом и текущим весом больше установленного порога, Monitor Daemon устанавливает вес сервера в соответствии с расписанием IPVS в ядре. Через определенный промежуток времени (например, 2 секунды) Monitor Daemon запрашивает состояние каждого сервера и соответствующим образом корректирует вес сервера, что происходит периодически. Можно сказать, что это механизм отрицательной обратной связи, поэтому сервер поддерживает лучшую степень использования.
В алгоритме взвешенного циклического планирования, когда вес сервера равен нулю, установленное соединение будет по-прежнему обслуживаться сервером, и новое соединение не будет назначено серверу. Системный администратор может установить вес сервера равным нулю, чтобы сервер работал тихо. Когда все существующие подключения завершены, он может отключить сервер и поддерживать его. Работы по техническому обслуживанию незаменимы для системы, такие как обновление оборудования и программного обеспечения, а нулевой вес делает тихую работу сервера очень важной. Поэтому мы должны обеспечить эту функцию в механизме балансировки нагрузки с динамической обратной связью. Когда вес сервера равен нулю, мы не регулируем вес сервера.
Комплексная нагрузка
При расчете общей нагрузки мы в основном используем два типа информации о нагрузке: индикаторы ввода и индикаторы сервера. Входные метрики собираются в планировщике, в то время как метрики сервера представляют собой различную информацию о нагрузке на сервер. Мы используем интегрированную нагрузку, чтобы отразить текущую точную нагрузку на сервер. Для разных приложений будут разные условия нагрузки. Здесь мы вводим коэффициент каждой информации о нагрузке, чтобы указать, что информация о нагрузке важна в комплексной нагрузке. Системный администратор корректирует коэффициент загрузки каждой информации в соответствии с потребностями различных приложений. Кроме того, системный администратор устанавливает интервал времени для сбора информации о нагрузке.
Индикатор ввода — это, в основном, отношение количества новых соединений, полученных сервером, к среднему количеству соединений в единицу времени, которые собираются в планировщике, поэтому этот показатель является оценкой нагрузки на сервер. В планировщике имеются счетчики для числа соединений, полученных каждым сервером, для сервера Si можно получить значения счетчиков Ci1 и Ci2 в моменты времени T1 и T2, а также можно рассчитать количество новых соединений, полученных сервером Si в интервале времени T2-T1. Ni = Ci2-Ci1. Таким образом, число новых соединений , полученных сервером Si в течение периода времени T2-T1, получается от сервера Si. Индикатор ввода INPUTi сервера Si представляет собой отношение количества новых соединений к среднему количеству соединений, полученных n серверами. Формула
Индекс сервера в основном записывает различную информацию о загрузке сервера, такую как текущая загрузка CPUi сервера, текущее использование Di диском сервера, текущее использование памяти Mi и текущее число процессов Pi. Есть два способа получить эту информацию: один — запустить процесс службы SNMP (Simple Network Management Protocol) на всех серверах, а демон мониторинга в планировщике запрашивает каждый сервер через SNMP для получения этой информации, второй — на сервере. Агент, который реализует и запускает сбор информации на компьютере, будет регулярно сообщать информацию о загрузке демону монитора. Если сервер не отвечает в течение установленного интервала времени, демон мониторинга считает, что сервер недоступен и устанавливает вес сервера в планировщике равным нулю, новые подключения не будут назначены серверу, если в следующий раз Сервер отвечает, а затем настраивает вес сервера. Затем обработайте данные таким образом, чтобы они попадали в диапазон [0, ∞), 1 означает, что нагрузка правильная, больше 1 означает, что сервер перегружен, а менее 1 означает, что сервер находится в состоянии низкой нагрузки. Скорректированные данные: DISKi, MEMORYi и PROCESSi.
Другим важным индикатором сервера является время отклика службы, предоставляемой сервером, которое может лучше отражать длину очереди ожидания запроса и время обработки запроса на сервере. Демон мониторинга в планировщике в качестве клиента получает доступ к службе, предоставляемой сервером, и измеряет время отклика. Например, чтобы проверить задержку ответа при получении HTML-страницы с веб-сервера, Monitor Daemon просто отправляет запрос «GET /» на каждый сервер, а затем записывает время ответа. Если сервер не отвечает в течение установленного интервала времени, демон мониторинга считает, что сервер недоступен и устанавливает вес сервера в планировщике равным нулю. Аналогично, мы скорректировали время отклика, как указано выше, чтобы получить RESPONSEi.
Здесь мы вводим набор коэффициентов Ri, которые можно динамически регулировать для представления важности каждого параметра нагрузки, где ΣRi = 1. Полная нагрузка может быть рассчитана по следующей формуле:
Например, в кластере веб-серверов мы используем следующие коэффициенты и считаем, что загрузка ЦП сервера и время ответа на запрос важнее других параметров. Если текущий коэффициент Ri плохо отражает загрузку приложения, системный администратор может непрерывно изменять коэффициент до тех пор, пока не будет найден набор коэффициентов, близких к текущему приложению.
Кроме того, что касается установки временного интервала запроса, хотя короткий интервал может более точно отражать нагрузку на каждый сервер, но частые запросы (например, несколько раз в секунду) будут приносить определенную нагрузку на планировщик и сервер, такие как Часто выполняемый Monitor Daemon будет иметь определенные накладные расходы в планировщике, и частый запрос индикаторов сервера также приведет к определенным накладным расходам на сервере. Поэтому существует компромисс (Tradeoff), мы обычно рекомендуем устанавливать интервал времени от 5 до 20 секунд.
Когда сервер используется в кластерной системе, системный администратор устанавливает начальный вес DEFAULT_WEIGHTi для сервера, который также используется первым в планировании IPVS ядра. Затем, по мере изменения нагрузки на сервер, веса корректируются. Чтобы вес не стал большим, мы ограничиваем диапазон веса [DEFAULT_WEIGHTi, SCALE * DEFAULT_WEIGHTi]. SCALE настраивается, и его значением по умолчанию является 10.
Monitor Daemon запускается периодически, если DEFAULT_WEIGHTi не равен нулю, а затем запросить каждый параметр загрузки сервера и вычислить полное значение нагрузки AGGREGATE_LOADi. Мы вводим следующую формулу расчета веса, чтобы настроить вес в соответствии со значением полной нагрузки сервера.
В формуле 0,95 — это коэффициент использования системы, которого мы хотим достичь, а A — это регулируемый коэффициент (значение по умолчанию — 5). Когда значение интегрированной нагрузки составляет 0,95, значение веса сервера не изменяется, когда значение интегрированной нагрузки больше 0,95, значение веса становится меньше, а когда значение интегрированной нагрузки меньше 0,95, значение веса становится больше. Если новый вес больше, чем SCALE * DEFAULT_WEIGHTi, мы устанавливаем новый вес на SCALE * DEFAULT_WEIGHTi. Если разница между новым весом и текущим весом превышает установленное пороговое значение, новый вес задается в параметрах планирования IPVS в ядре, в противном случае избегаются накладные расходы на планирование IPVS. Мы можем видеть, что это формула отрицательной обратной связи, которая будет корректировать вес до стабильной точки. Например, когда система достигает идеального коэффициента использования, вес не изменяется.
В реальных условиях, если вес всех серверов оказывается меньше, чем их DEFAULT_WEIGHT, это означает, что весь кластер серверов перегружен. В это время необходимо добавить новый узел сервера в кластер для обработки части нагрузки, в противном случае, если все серверы имеют Веса близки к SCALE * DEFAULT_WEIGHT, что указывает на то, что текущая загрузка системы относительно невелика.
Пример реализации
Мы реализовали простой алгоритм динамической балансировки нагрузки с обратной связью в инструменте управления кластером RedHat Piranha. Что касается общей нагрузки, он учитывает только загрузку процессора (средняя загрузка) сервера и использует следующую формулу для регулировки веса:
Интервал регулировки веса сервера равен [DEFAULT_WEIGHTi, 10 * DEFAULT_WEIGHTi], A — DEFAULT_WEIGHTi / 2, а порог регулировки веса — DEFAULT_WEIGHTi / 4. 1 — желаемое использование системы. Piranha запрашивает загрузку ЦП каждого сервера каждые 20 секунд, чтобы выполнить расчет и настройку веса.
Вычисляемая на коленке нагрузка на сервер (ОЗУ), дабы выбрать хостинг
Статья будет совсем короткая, ибо для большинства идеальное решение — простое решение (не путать с правильными и разными ибо правильных много).
Статья о том, как это делал Я при отсутствии инструментария вообще.
- Первичный хостинг — девелоперская машина в офисе/дома на реальном IP, где и разворачиваем открытый бета-тест и запускаем людей.
- Выясняем время сессии РНР. Обычно это 15 минут.
- Делим сутки на 96 участков по 15 минут (24ч*60мин/ч=3600мин/15мин)
- Пишем скрипт-надстройку, которая в начале кода любого проекта/движка тупо регистрирует ip визитёра в свой участок 15-мин промежутка.
- Работаем так 2 недели.
Не раз повторю, что всё изложенное — вычисления на коленке.
- Максимум уникалов/15-мин
- Максимум хитов / 15 минут
Механика:
Допустим у нас в 15 минут 250 уникалов, которые смотрят каждый по (в среднем арифметическом, кто 9, а кто 2. ) 6 страниц.
Это 250*6=1500 хитов / 15 минут.
15 минут = 15мин*60сек/мин = 900 сек.
В секунду просматривается 1.6(66) страниц ( ceil( 1500хитов / 900сек ) ) = 2 страницы в пике нагрузки за 1 секунду.
Если знаем пиковое значение времени генерации страницы (тут уж от проекта зависит), скажем от запроса до окончания отдачи — 2 секунды (без времени передачи файлов, но включающее работу с БД), то получаем 2 стр/сек * 2 сек = 4 стр/сек пиковую нагрузку на наш веб-сервер.
- 1 php-процесс, согласно php.ini по дефолту жрёт 128 мег. 4 стр/сек * 128мб = 512 мег в секунду кушает php;
- предполагается, что вы уже настроили свою бд относительно потребления памяти и это число, например, равно 1гб памяти (у кого-то и 4гб, а у кого-то и 512мб)
- сама операционка, если это линукс/юникс, занимающийся только хостингом кушает в среднем 512-1024мб, зависит от многих параметров и софта.
Итого нам требуется памяти от 2гб до 3гб. Точность вычисления — 85-90% , тоесть люфт 15%-10% и уже от вас и проекта зависит в какую сторону.
По нагрузке на процессор механика вычисления похожа, но за единицы измерения уже берётся время генерации страницы, как «информация» , без оглядки на время запросов, — нам нужна конечная информация, а не составляющие её данные. Там вычисления либо по load average процессора либо по % нагрузки на процессор текущего процесса php.
PS:
Я прошу не привязываться к пунктам 2-3, это вычисления на коленке, но как ни странно показывающие приближённую реальность. Обычно (согласно личному опыту), это названные 85-90% и этого, поверьте — достаочно для старта продакшена.
Так же названные «96 участков времени» призваны установить видимые границы времени. Не более.
В итоге, нам надо выяснить пиковую нагрузку в количестве уникалов/хитов на объём 15-минутной рнр-сессии (это время процессора и мегабайты озу), за время которой и можно поймать этих уникалов.
PPS:
Вообще если кто-то заказывает проект, то он уже должен знать текущую аудиторию, её размер, предварительно проведя аналитику рынка. Соответственно от вас требуется только выяснить:
[время генерации страницы] * ( [Х-хитов] / [время сесии php в секундах] ) = [пиковая нагрузка на сервер за 1сек] * [объём потребления памяти процессом php] = [требования по памяти для php]
Соответственно мы видим необходимый объём памяти под php-проект. Останется плюсануть потребности БД и операционки.
PPPS:
Ну а если НЕ хотите делать вычисления на коленке, переложив всю работу на других — ставьте Яндекс.Метрику (не реклама), она покажет вам даже больше аналитики и точнее И debug-надстройку с возможностью сохранять потребления в бд, для последующих (через пару недель) выборок статистики. Однако там также всё не просто, как и с вышеизложенным. В любом случае придётся попотеть.
Прошу особо не пинать за настолько грубые вычисления и привязку к сомнительным «якорям» , ибо этот метод, как я и говорил — вычисления на коленке при отсутствии какого-либо инструментария вообще. Точность проверена личным опытом в нескольких (5) проектах ещё 10 лет назад, и составила названные 85-90% с реальным люфтом в виде остатка 15-10% (2 проекта ушли в плюс, 3 в минус).
А методика, с некоторыми правками, сдёрнута ещё в начале 2000х с какого-то буржуйского сайта, тогда это было модно.
Алгоритмы и методы распределения нагрузки на сервер
Нагрузка на сервер — это динамическая величина, поведение которой можно предсказать лишь с небольшой долей точности. Владелец сайта никогда не знает наверняка, будут ли скачки нагрузки в ближайшее время. С небольшим увеличением числа посетителей могут справиться простые меры: подключение дополнительных вычислительных мощностей сервера, оптимизация уже настроенных алгоритмов и кода. Но резкий и мощный скачок посещаемости может временно вывести сайт из строя, несмотря на принятые меры. Для владельца портала это печальный исход — потенциальные покупатели и клиенты пойдут искать более устойчивый ресурс и вряд ли вернутся на упавший сайт, а вебмастер потеряет прибыль. Поэтому при подготовке сервера приходится уделять внимание распределению и балансировке нагрузки.
Балансировка нагрузки
Балансировка нагрузки предполагает, что у вебмастера есть в распоряжении несколько серверов (реальных или виртуальных), образующих кластер. Набор серверов, используемых для обслуживания одного сайта, также называют пулом. Метод балансировки позволяет распределять нагрузку между серверами из пула.
Как работает
В дополнение к основному серверу портала владелец сайта подключает пул серверов для балансировки. Каждый запрос пользователя проходит через набор алгоритмов, которые выбирают, на какой сервер направить текущего посетителя. Например, можно задать простой алгоритм и направлять каждого посетителя сайта на сервер с минимальной на текущий момент загруженностью.
Какие проблемы решает
Другое название этого комплекса мер — выравнивание нагрузки (load balancing). Эти методы повышают отказоустойчивость сайта, увеличивают его быстродействие, упрощают горизонтальное масштабирование кластера и позволяют делать резервные копии на нескольких серверах сразу.
Большая нагрузка на сервер хостинга может навредить и сайтам-соседям. Поэтому большинство хостеров предлагают готовые решения по определению и балансировке загруженности.
Три уровня балансировки
Выделяют балансировку на трех уровнях: сетевом, транспортном и прикладном. Можно распределять нагрузку как на одном уровне, так и на нескольких сразу.
Сетевой
Этот метод предполагает использование набора физических серверов. Это достаточно дорогой, но очень эффективный метод, который надежно защищает вебмастера от превышения нагрузки на сервер. Суть его сводится к тому, что несколько разных машин отвечают за работу одного IP-адреса.
Глобальные проекты часто используют сетевую балансировку по территориальному признаку. Для этого физические серверы, отвечающие за работу портала, размещают в различных регионах интернета. Пользователи распределяются по серверам в зависимости от своей геопозиции.
На сетевом уровне можно настроить распределение нагрузки на сервер такими методами:
- Выравнивание через DNS. За доменным именем закрепляются несколько IP-адресов.
- NLB-кластер. Несколько физических серверов объединяют в кластер, состоящий из входных и вычислительных узлов. Обычно этот метод используется в Microsoft.
- IP-адрес. К сети добавляется маршрутизатор, который и распределяет нагрузку по адресам.
Транспортный
Этот тип методов отличается простотой и эффективностью. Транспортное снижение нагрузки на сервер предполагает использование балансировщика, который распределяет запросы по пулу в соответствии с заданными алгоритмами. Балансировщик передает выбранному серверу запросы, а затем получает на них ответ и перенаправляет его обратно пользователю. Самые простые (но при этом популярные) из транспортных алгоритмов — элементарный круговой перебор (каждый запрос будет направляться на следующий сервер) и поиск наименее загруженного сервера.
В чем принципиальная разница между сетевыми и транспортными методами? Первые просто перенаправляют запросы. Затем выбранный сервер напрямую обменивается данными с клиентом. Транспортные методы работают как прокси — они сами обмениваются данными с сервером, а не связывают клиента и сервер напрямую.
Прикладной
Прикладная балансировка похожа на транспортную — здесь тоже используется прокси, и запросы пользователей передаются на серверы. Но, в отличие от транспортной балансировки, прикладная распределяет нагрузку с учетом запрашиваемых страниц, контента или действий. Например, запись на сайт (создание учетных записей и подобные действия) будут проводиться через один сервер, а чтение — через другой. Можно распределить нагрузку по типу контента (аудио, видео, изображения, текст).
Для прикладного и транспортного методов подходят как физические, так и виртуальные серверы. Оптимальный вариант — зарезервировать виртуальный VDS сервер под эти нужды.
Допустимая нагрузка на сервер — что это, как измерить и зачем
Рассказываем, что такое нагрузка на сервер, какие причины ее возникновения и как исправить.
На тарифах виртуального хостинга существуют некоторые ограничения — например, допустимая нагрузка на процессор сервера в день. Это вызвано особенностями размещения аккаунтов. На одном мощном сервере расположены разные сайты, которые делят между собой его ресурсы. Чтобы все сайты работали стабильно, существуют лимиты по нагрузке на сервер, базы данных и использование оперативной памяти.
Чтобы было понятнее, проведем простую аналогию. Представьте себе коммунальную квартиру, в которой живут две семьи. В каждой семье по три человека. Утром все собираются на работу или в школу, и всем для этого нужна ванная комната. Если распределить время поровну — например, по 10 минут, то все успеют по своим делам. Но если кто-то из жителей займет комнату на 20 минут, другой — на 30, то остальные жители квартиры не успеют собраться.
Похожая ситуация возникает с ресурсами сервера. Если один из аккаунтов хостинга будет потреблять 90% процессорных ресурсов, то остальным достанется всего 10%. Чтобы не допустить такой ситуации, существуют лимиты допустимой нагрузки. Они помогают распределить ресурсы равномерно.
Использование ресурсов сервера на виртуальном хостинге
Причины и последствия нагрузки на сервер
По нашему опыту рост нагрузки является следствием одной или нескольких причин:
- резкий рост посещаемости;
- ошибочный или не оптимизированный программный код сайта;
- наличие вредоносного кода на сайте;
- отключенная или некорректная настройка системы кеширования.
При нарушении лимита нагрузки владельцу аккаунта придет предупреждение. В письмах от Reddock приведены показатели сайта по нагрузке и рекомендации по устранению. Если в течение 5 дней ситуация не исправляется, аккаунт блокируют. Это сделано для того, чтобы гарантировать работу всех сайтов, расположенных на одном сервере. После устранения нагрузки работа сайта возобновляется.
Как узнать текущую нагрузку на сервер и что делать, если сайт превышает лимиты
Посмотреть статистику нагрузки на сервер можно в панели управления виртуальным хостингом (инструкция). Если показатели в норме, то можно не беспокоится и проверить данные позже — например, при выгрузке товаров из 1С.
Если показатели близки к пороговой границе, то это сигнал для тревоги — вскоре придет предупреждающее письмо. Уже на этом этапе нужно предпринимать действия для выявления и устранения высокой нагрузки. Для этого можно воспользоваться встроенными в вашу CMS инструментами диагностики, специальными инструментами-профайлерами или провести анализ лог-файлов.
Не всегда есть возможность снизить нагрузку на сервер. Например, если бизнес развивается, количество посетителей сайта растет, товаров становится больше и синхронизация со сторонними сервисами создает высокую нагрузку. В этом случае оптимальным решением будет переход тариф виртуального сервера.
Размещение сайтов на виртуальном сервере — у каждого свои ресурсы
Виртуальный сервер — отличный вариант для нагруженных корпоративный сайтов и интернет-магазинов, которым не хватает ресурсов виртуального хостинга. На одном мощном сервере размещается несколько сайтов, у каждого из которых свои ресурсы — гарантированная оперативная память, дисковое пространство и допустимая нагрузка на сервер.