Как рассчитать нагрузку на сервер
Перейти к содержимому

Как рассчитать нагрузку на сервер

  • автор:

Как спрогнозировать нагрузку на сайт?

Как определить какая будет нагрузка на сайт при N посетителях в сутки. То есть к примеру если в сутки заходит 5000 пользователей, то среднее одновременное количество пользователей сколько будет? 50 пользователей одновременно, есть какие-то варианты? К примеру если я хочу на свой сайт 100 000 пользователей в сутки, на какую нагрузку должен ращитывать? 1000 пользователей одновремено или сколько? Как вообщем расчитать возможную нагрузку в зависимости от возможного числа поситителей?

На сайте с 31.08.2009
25 мая 2011, 02:43

Таких готовых формул расчета не существует, и не может существовать. О 100 000 посетителей в сутки можно только мечтать — причем не один год :), лучший выход такой : начать с простого шаред хостинга, и по мере возникновения нагрузки уже решать эту проблему (оптимизировать, кешировать, потом менять тариф или переезжать на VPS, потом брать дедик и т.д.) На практике же хватает шареда на начальном этапе.

Потому что Drupal — это круто.
25 мая 2011, 03:06

Дану как не существует, даже средняя температура по больнице ито показатель, а если говорить о максимальной температуре по больнице и минимальной, то это ваще показатель, дай бог что бы не матерится какой огого. тоже самое и тут, если допустим при 5 000 пользователей в сутки вариируется количество одновременных пользователей от 5 до 1000, то это уже огого какой показатель, но думаю с 5000 поользователей 1000 одновременных в статистику не попадет, так как таких сайтов скорее вообще нет будет вариироватся допустим от 5 до 100 но это же тоже уже показатель, а может от 5 до 10.. кто его знает. Вот если кто-то может на примере привести цифры то это уже показатель, а так понятно, что на цену вопроса влияет: 1. Проложительность нахождения на сайте пользователя 2. Количество пользователей в сутки 3. график распределения Если допустим среднее время пребывания на сайте 5 минут. И в течении 5 часов сайт посещает 50 % пользователей тогда максимальная нагрузка при 5000 пользователей будет: 2500 делить на 60 = 41 пользователь, а точность такой оценки будет, если считать, что посещение всеми пользователями сайта за 3 часа является невозможно редким. то максимально возможное количество 141 пользователь. то есть при 3 часах точность оценки 29% при 5 часах точность оценки 49%, при 8 часах, точность оценки 79% то есть если в ерить, что все пользователи на сайте могут в принципе сгущатся в 8 часов использования, что вполне реально хотя немного завышенно так как спим 8 часов бодрствуем 16. следовательно распределение будет приближатся к 16 часам для региона, а сгущатся в приделах 10 часов. То в принципе прогноз максимального количества пользователей в числе 41 человека при 5000 вполне реальный.

Методология расчета нагрузки, количества пользователей информационной системы — 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 миллиона домохозяйств России) и процент их охвата в колонке «наши пользователи»

Для системы описанной в примере итоговый результат выглядит так:

Понятно что Система создана совсем простая как и профиль пользователя простейший – осуществляющим простые операции.
Так же нужно иметь в виду и уметь пользоваться при прогнозах аналитическими отчетами к примеру – ОТРАСЛЕВОЙ ДОКЛАД. Федеральное агентство по печати и массовым коммуникациям Интернет в России Состояние, тенденции и перспективы развития.
или
Мобильный интернет России.
Интересно было смоделировать расчетную модель на более сложном профиле пользователя и системе – улучшить методику.

  • расчет посещаемости
  • расчёт нагрузок
  • нагрузка
  • прогнозирование

Рассчитываем нужную производительность сервера

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

Что влияет на скорость работы сервера?

Скорость работы сервера — комплексная метрика, которая описывает время, за которое браузер получает ответ от хостинга и выдает пользователю нужную страницу. На скорость работы влияет:

  • Тип контента (вес сайта)
    При выборе хостинга нужно учесть тип контента, который будет размещаться на ресурсе, а также объемы сайта и количество страниц. Например, если для интернет-магазина был выбран хостинг с небольшим объемом памяти, ресурс будет загружаться очень долго. Разберитесь с этим заранее, чтобы точно рассчитать, сколько оперативной памяти нужно серверу.
  • Качество контента
    Даже если у вас небольшое количество станиц, но сложная верстка и анимация — это будет влиять на скорость загрузки страниц. Частая ситуация — корпоративный сайт (8-10 страниц) с анимацией, 3D-моделями работ в движении и прочими «декоративными» элементами. Такой сайт может загружаться по 10-15 секунд.
  • Нагрузка
    Здесь выделяют понятие «пиковой нагрузки» — это максимальное количество переходов на площадку в единицу времени. Если пиковая нагрузка произошла неожиданно, то сайт забирает все свободные ресурсы хостинга, чтобы выдержать поток пользователей. В этот момент другие площадки на этом же хостинге могут «лечь» из-за отсутствия мощностей. Важно учитывать это, чтобы понять, какой процессор выбрать для сервера.
  • Версия PHP
    Это язык для работы с формами на сайте или для создания CMS. Чем старше версия, тем дольше контент обрабатывается. Чтобы проверить, какая версия у вас, перейдите в панель управления своим хостингом.
  • CMS
    CMS — конструктор для сайтов. У всех CMS есть существенный недостаток — они снижают скорость загрузки.
  • Дополнительная функциональность
    Если на площадке вы используете дополнительные скрипты и плагины (например, виджеты чата), это увеличивает вес сайта и нагрузку на сервер.

Как рассчитать требуемую производительность сервера?

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

Зачем нужно рассчитывать требуемую мощность?

Расчет мощности сервера помогает выбрать провайдера услуг. Если нагрузка будет несоразмерной, вас ждет несколько проблем:

  1. Низкая конверсия сайта
    Чем дольше пользователь ждет, тем меньше конверсия площадки. У вас 6 секунд, чтобы дать клиенту то, что ему нужно, иначе он просто закроет вкладку и уйдет к конкурентам.
  2. Проблемы с администрацией хостинга
    Если вы не используете отдельный сервер, а разместили свой сайт на общем хостинге, то важно учитывать, что при перегрузке вы будете забирать себе свободные мощности сайтов-соседей.

Перед тем, как выбрать хостинг-провайдера, ответьте на несколько вопросов:

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

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

Оценка производительности сервера

Никто ведь не хочет увидеть подобную картину, когда сервер будет уже в работе?

При выборе хостинг-провайдера важно убедиться, чтобы поставщик может гарантировать обслуживание, о котором заявляется. Чтобы проверить производительность сервера, воспользуйтесь специальной утилитой Geekbench. Подробная инструкция оценки производительности сервера здесь.

Подбираем подходящую конфигурацию оборудования

После испытаний на эталонной системе у вас на руках есть четкое ТЗ, какое оборудование вам нужно:

  • Процессор
    Обеспечивает работу сервера, чем больше ядер, тем больше процессов может выполняться одновременно.
  • Дисковая подсистема (накопитель)
    Выбирается, исходя из задач, которые вы сформулировали ранее. Например, если вам нужно будет часто делать резервные копии — выбирайте HDD. Единственный недостаток такого накопителя — низкая производительность. Если скорость работы для вас в приоритете, лучше взять SSD. У них производительность больше в 2 раза. Более современный вариант SSD NVMe.
  • Объем оперативной памяти
    Также рассчитывается под конкретную задачу. Минимальный объем 512 Мб подходит для небольшого лендинга. Если у вас большой сайт-каталог с вложенными страницами и дополнительной функциональностью, то памяти нужно больше. Чтобы понять, сколько оперативной памяти нужно серверу, вернитесь к результатам теста эталонной системы.

Какой процессор выбрать для сервера?

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

На что ориентироваться при выборе процессора:

  • Сколько ядер нужно?
    Ядро в процессоре отвечает за скорость обработки параллельных процессов. Максимум их может быть 24. Не стоит бездумно брать самый большой объем. Во-первых, это существенно увеличивает стоимость, а во-вторых, лучше делать упор на частоту ядер, а не на их количество.
  • Объем памяти для кэша
    Эта память отвечает за скорость обработки запросов. Чем она больше, чем быстрее работает процессор. Рекомендуем выбрать память от 8 до 16 Мб.
  • Сокет
    Проверьте, что сокет процессора совместим с материнской платой, иначе соединение будет некачественным, и скорость работы снизится.
  • Тактовая частота
    Это количество вычислений, которые процессор может выполнить за 1 секунду. Важный критерий, если ваш ресурс постоянно должен обрабатывать много однотипных задач.
  • Отвод тепла
    Процессор должен быть оснащен современной системой охлаждения, чтобы избежать перегрева.

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

Планирование нагрузки на сервер

Планирование нагрузки на сервер

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

Простая на первый взгляд задачка

Дан сервер, синхронно обрабатывающий запросы из Интернет в одном потоке. Т.е. в каждый момент времени сервер может либо обрабатывать один запрос, либо ожидать новые запросы. Запросы становятся в очередь ожидания, если в данный момент сервер занят обработкой другого запроса. Время обработки одного запроса равно 100 мс. Каково будет среднее время ожидания запроса в очереди при средней нагрузке на сервер в 10 запросов в секунду? Правильный ответ — время ожидания будет стремиться к бесконечности. Как же так? Ведь очевидно, что за одну секунду сервер может последовательно обработать 10 запросов. Откуда тогда берется бесконечность? Дело в том, что средняя и равномерная нагрузка — это «две большие разницы». Средняя нагрузка на сервер может быть представлена в виде процесса Пуассона. Это означает, что в начале первой секунды может сразу прийти 100 запросов, а за последующие 9 секунд — ни одного. В итоге выходит 10 запросов в секунду за интервал в 10 секунд со средним временем ожидания sum(1..99)/100 * 100 мс = 4.95 секунды. С увеличением рассматриваемого интервала увеличивается и среднее время ожидания. Если рассматривать среднее время ожидания на бесконечном интервале времени, то оно тоже устремится в бесконечность. Рассмотрим другие варианты. Очевидно, что при средней нагрузке, превышающей 10 запросов в секунду, сервер не сможет обрабатывать лишние запросы, что приведет к бесконечному увеличению очереди ожидания запросов. А что будет, если нагрузка будет ниже максимально допустимой? Например, каково будет среднее время ожидания при 95% нагрузке, т.е. для нашего случая 9.5 запросов в секунду? Думаете, 0мс или что-то близкое к этому? Ведь при такой нагрузке сервер должен простаивать в ожидании запросов 5% своего времени. Спешу вас снова огорчить — среднее время ожидания в этом случае будет равно 950 мс, т.е. в 9.5 раз больше времени, необходимого на обработку самого запроса! Идем дальше. Давайте попробуем предположить время ожидания при 90% нагрузке. Нет, вовсе не 900 мс, а 450 мс. Интересно. А при какой нагрузке среднее время ожидания будет равно времени, необходимому для обработки запроса? Иными словами, при какой средней нагрузке среднее время ответа от сервера будет равно 200 мс (100мс ожидание + 100мс обработка)? Правильный ответ — 66.666. %! Даже при одном запросе в секунду среднее время ожидания будет равно не нулю, а где-то 5.56 мс.

Мы тебе не верим. Откуда такие странные числа?

Числа получены экспериментальным путем, после чего была выведена формула. Вот функция, написанная на python, которая была использована для моделирования нагрузки на сервер и вычисления среднего времени ожидания.

def NormalizedAvgWaitTime(load_factor, requests_count): """Calculates normalized average wait time for the given load factor. Models requests to a synchronous single-threaded server using Poisson process and calculates an average wait time per request for the given load factor. Args: load_factor: a floating point value in the range [0..1). The value 0 means the server isn't loaded with requests at all, the value 1 means the average qps load on the server is equivalent to its' maximum capacity. requests_count: an integer representing the number of requests to model. Higher values mean higher precision for the returned result. Returns: a floating point number representing normalized average wait time per request for the given load factor. The value 0 means requests are processed immediately, while any number W means requests stay in the queue for an average W*T seconds, where T is a time required for processing a single request on the idle server. """ if not load_factor: return 0 points = sorted(random.random() for i in range(requests_count)) request_time = load_factor / requests_count total_wait_time = 0 x = points[0] for i in range(1, requests_count): y = points[i] wait_time = request_time - y + x if wait_time > 0: total_wait_time += wait_time y += wait_time x = y return total_wait_time / load_factor

А вот тут вы можете удостовериться в подлинности вышеприведенных чисел и посмотреть, как requests_count влияет на точность вычислений. Заодно в python попрактикуетесь. После того, как были получены экспериментальные данные, осталось подогнать под них формулу 🙂 При load_factor = 1 наша функция стремится к бесконечности. Значит, у нас должна быть дробь, в знаменателе которой присутствует множитель, стремящийся к нулю при load_factor = 1. На эту роль хорошо подходит (1 — load_factor). Идем дальше. При load_factor = 0 наша функция равна нулю. Значит, в числителе дроби должен быть множитель, равный нулю при load_factor = 0. Очевидно, что это и есть load_factor. Дальше — при load_factor = 0.5 наша функция должна равняться тоже 0.5 . Значит, C*0.5/(1-0.5) = 0.5 . Откуда C = 0.5 . В итоге формула принимает вид:

NormalizedAvgWaitTime(load_factor) = 0.5*load_factor/(1-load_factor)

Где-то должен существовать аналитический вывод этой формулы посредством матаппарата процесса Пуассона, но там, скорее всего, слишком много матана, который не очень интересен и не совсем понятен основной аудитории этой статьи. Уверен, в Интернете полно материалов по этой теме, так что желающие могут погуглить самостоятельно. Может оказаться, что моя модель с формулой не совсем корректна.

Многопоточные сервера, серверные кластеры и асинхронная обработка запросов

До сих пор мы рассматривали сферического коня в вакууме aka «однопоточный сервер, последовательно обрабатывающий независимые запросы в синхронном режиме». На практике такие сервера встречаются достаточно редко (если не считать Python runtime в Google AppEngine). Как же быть с многопоточными серверами, серверными кластерами и прочими асинхронными node.js’ами? Очень просто — для них тоже действует вышеописанная формула. Нужно лишь забыть о деталях реализации и представить наш сервер или кластер в виде black box’а, после чего определить максимальную нагрузку, которую способен выдержать этот black box, чтобы правильно откалибровать load_factor в формуле. Максимальную нагрузку, выраженную в запросах в секунду, можно определить следующим способом: отправляем нашему black box’у в максимально короткое время (чем меньше, тем точнее результат) фиксированное число real-world запросов (чем больше, тем точнее результат) и засекаем время, когда все они будут корректно обработаны. Затем делим количество обработанных запросов на время. Это и есть искомая максимальная нагрузка на нашу систему, относительно которой калибруется load_factor.

Как правильно планировать нагрузку на сервер?

К этому моменту вам должно быть понятно, что результаты типичного нагрузочного тестирования перед выходом в production не совсем корректно отражают объективную реальность. Главная проблема в том, что поток тестовых запросов не является Пуассоновским процессом, с которым суждено встретиться серверу в production. Но это легко поправимо. Достаточно найти максимальную нагрузку, выдерживаемую системой по схеме, описанной в предыдущем параграфе. После этого по формуле вычисляете допустимую нагрузку в production для заданного среднего времени ожидания запроса. Например, для максимальной нагрузки в 1000 qps и среднего времени ожидания запроса, равного 100% времени обработки запроса: 1 = 0.5*load_factor/(1-load_factor) => load_factor = 1/1.5 = 2/3. Тогда допустимая нагрузка равна 1000*2/3 = 666.666. qps.

Многопоточные программы

Можно ли применить только что полученные знания для вычисления среднего времени ожидания доступа к разделяемому ресурсу, защищенного с помощью блокировки в многопоточной программе? Ответ — нет, т.к. процесс доступа к разделяемому ресурсу из небольшого количества потоков (например, меньше тысячи) не может быть аппроксимирован Пуассоновским процессом. В многопоточных программах всегда известна максимальная нагрузка на доступ к разделяемому ресурсу — она пропорциональна максимальному количеству потоков, которые могут захватить блокировку. Более того, для простейшей реализации блокировок в виде FIFO очереди заблокированных потоков всегда известно максимальное время ожидания — оно пропорционально максимальному количеству потоков и времени удерживания блокировки.

Заключение

Всегда следите за нагрузкой на системы, обрабатывающие запросы, которые распределены во времени по процессу Пуассона. К таким системам относятся все системы с потенциально большим количеством пользователей. Например, все сервера подключенные к Интернет. Не допускайте, чтобы средняя нагрузка повышалась более 75% от максимально допустимой, т.к. это ведет к молниеносному увеличению среднего времени ожидания входящих запросов. Грамотно интерпретируйте результаты нагрузочного тестирования.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *