Рассчитываем нужную производительность сервера
Одной из самых важных задач на этапе запуска сайта является выбор подходящей конфигурации сервера. Серверная производительность влияет на скорость загрузки страниц. Более 70% пользователей признают, что если сайт открывается дольше 6 секунд, они закрывают страницу. В этой статье рассказываем, как сделать расчет мощности сервера.
Что влияет на скорость работы сервера?
Скорость работы сервера — комплексная метрика, которая описывает время, за которое браузер получает ответ от хостинга и выдает пользователю нужную страницу. На скорость работы влияет:
- Тип контента (вес сайта)
При выборе хостинга нужно учесть тип контента, который будет размещаться на ресурсе, а также объемы сайта и количество страниц. Например, если для интернет-магазина был выбран хостинг с небольшим объемом памяти, ресурс будет загружаться очень долго. Разберитесь с этим заранее, чтобы точно рассчитать, сколько оперативной памяти нужно серверу. - Качество контента
Даже если у вас небольшое количество станиц, но сложная верстка и анимация — это будет влиять на скорость загрузки страниц. Частая ситуация — корпоративный сайт (8-10 страниц) с анимацией, 3D-моделями работ в движении и прочими «декоративными» элементами. Такой сайт может загружаться по 10-15 секунд. - Нагрузка
Здесь выделяют понятие «пиковой нагрузки» — это максимальное количество переходов на площадку в единицу времени. Если пиковая нагрузка произошла неожиданно, то сайт забирает все свободные ресурсы хостинга, чтобы выдержать поток пользователей. В этот момент другие площадки на этом же хостинге могут «лечь» из-за отсутствия мощностей. Важно учитывать это, чтобы понять, какой процессор выбрать для сервера. - Версия PHP
Это язык для работы с формами на сайте или для создания CMS. Чем старше версия, тем дольше контент обрабатывается. Чтобы проверить, какая версия у вас, перейдите в панель управления своим хостингом. - CMS
CMS — конструктор для сайтов. У всех CMS есть существенный недостаток — они снижают скорость загрузки. - Дополнительная функциональность
Если на площадке вы используете дополнительные скрипты и плагины (например, виджеты чата), это увеличивает вес сайта и нагрузку на сервер.
Как рассчитать требуемую производительность сервера?
Правильный расчет нужен, чтобы обеспечить стабильную работу сайта, но сэкономить бюджет, не переплачивая за мощности, которыми вы не будете пользоваться.
Зачем нужно рассчитывать требуемую мощность?
Расчет мощности сервера помогает выбрать провайдера услуг. Если нагрузка будет несоразмерной, вас ждет несколько проблем:
- Низкая конверсия сайта
Чем дольше пользователь ждет, тем меньше конверсия площадки. У вас 6 секунд, чтобы дать клиенту то, что ему нужно, иначе он просто закроет вкладку и уйдет к конкурентам. - Проблемы с администрацией хостинга
Если вы не используете отдельный сервер, а разместили свой сайт на общем хостинге, то важно учитывать, что при перегрузке вы будете забирать себе свободные мощности сайтов-соседей.
Перед тем, как выбрать хостинг-провайдера, ответьте на несколько вопросов:
- Какой будет площадка?
Требования к функциональности сервера для интернет-магазина с функцией мультирегиональности и простому лендингу совершенно разные. - Какой будет дополнительный функционал?
Использование ПО, наличие дополнительного функционала, например возможности пройти демо-версию продукта на текущем сайте. В случае интернет-магазина это работа с товарной базой (чаще всего с 1С). - Есть ли данные о нагрузках и поведении пользователей?
Если вы заранее знаете, что на ресурс будет большое количество переходов, это важно учесть при выборе хостинга. Если мощностей будет не хватать, сайт будет постоянно зависать, что скажется на результатах выдачи.
После того, как вы ответили на все эти вопросы, для расчета мощности сервера необходимо выбрать эталонную и целевую системы. Эталонная — копирует целевую, на ней будет проводиться тест. Вам нужно протестировать на эталонной системе минимальную и максимальную нагрузку. В результате эксперимента вы получаете четкие данные, что нужно доработать в целевой системе.
Оценка производительности сервера
Никто ведь не хочет увидеть подобную картину, когда сервер будет уже в работе?
При выборе хостинг-провайдера важно убедиться, чтобы поставщик может гарантировать обслуживание, о котором заявляется. Чтобы проверить производительность сервера, воспользуйтесь специальной утилитой 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% от максимально допустимой, т.к. это ведет к молниеносному увеличению среднего времени ожидания входящих запросов. Грамотно интерпретируйте результаты нагрузочного тестирования.
Помогите расчитать нагрузку на сервер потоковое аудио для 1 000 слушателей
Вот сколько способен один такой сервер вытянуть слушателей, приблизительно?
На что идет основная нагрузка, память, проц, сеть.
Буду признателен за любой комментарий по теме.
Покупаю жирные морды и сквозняки! Клевые мини экскаваторы и гидромолоты (http://kramer.su/) Kramer — навесное оборудование для Экскаваторов
- eTarget 2011:Панельная дискуссия «Стратегия и планирование рекламной кампании в интернете»
- eTarget 2011: Круглый стол «Реклама в онлайн-видео»
- Могут ли «плохие» входящие ссылки привести к ухудшению ранжирования?
На сайте с 23.10.2006
2 декабря 2009, 21:17
Проведите нагрузочное тестирование, т.к. более менее точный ответ вы не получите, т.к. неизвестен как минимум, ни битрейт, ни ПО на котором это все работает, ни ОС, ни размер вашего канала (а ведь это 128 kbps х 1000 уже больше 100Мбит/с + накладные расходы)
Заставьте сотрудников принести по ноутбуку, купите свич (500р), соедините все это проводами и запустите на каждом ноуте по 10-50 подключений к серверу, а дальше уже поймете что ваша система кушает больше.
На сайте с 13.08.2008
2 декабря 2009, 21:27
bimcom, ОС будет FreeBSD
Тестировать пока к сожалению нечего, разработка на стадии концепции.
Сервер будет на коллокейшене. Будем искать самый быстрый доступ к сети. У сервера 2 сетевые карты по 1 Гбит/с можно например подключить сразу две и распределить таким образом поток.
Мне хочется понять, какая аппаратная часть наиболее востребована. Нужна ли процессорная мощность, хватит ли 16Г оперативной памяти.
addgrom добавил 03.12.2009 в 00:27
bimcom, ОС будет FreeBSD
Тестировать пока к сожалению нечего, разработка на стадии концепции.
Сервер будет на коллокейшене. Будем искать самый быстрый доступ к сети. У сервера 2 сетевые карты по 1 Гбит/с можно например подключить сразу две и распределить таким образом поток.
Мне хочется понять, какая аппаратная часть наиболее востребована. Нужна ли процессорная мощность, хватит ли 16Г оперативной памяти.
Как рассчитать нагрузку на сервер
Не только те разработчики, кто уже год-два работает с крупными проектами с миллионными бюджетами, но и самые обычные средние студии всё чаще сталкиваются с заказами, проектами, которые подразумевают сотни тысяч, а то и миллионы хитов в день. Как правило, это современные интернет-магазины с очень большой номенклатурой товаров (например, магазин с 500 000 карточек товаров и 3 млн SKU) . Но могут быть и информационные и корпоративные проекты. Всё это надо как-то уметь проектировать, обслуживать, как-то с этим работать.
Создание проекта веб-студией надо рассматривать с двух сторон: с позиции менеджера и с технической. Игнорирование любой из них с высокой долей вероятности ведёт к провалу заказа. На практике, особенно в небольшой студии, развести эти моменты бывает достаточно сложно, так как, например, ведущий программист выступает, как правило, ещё и менеджером проекта. В нашем курсе обе этих стороны будут постоянно пересекаться, но мы постараемся выделять и отделять организационные моменты от технических.
Проблемы перед веб-студиями возникают как только они получают заказ на проект чуть более сложный, чем обычно. Немного более сложный, немного более большой, немного более высоконагруженный. (В рамках Bitrix Framework это означает, что как только запросы клиента выходят за пределы административной части, инфоблоков с контентом, то начинаются сложности.) В этом курсе мы постараемся дать простые методики как выжить в данном случае.
Надо понимать, что сложный проект и высоконагруженный проект – это немного разные вещи. Возможен высоконагруженный проект на штатном функционале CMS. В этом случае требуется, главным образом, настройка серверов. И возможен сложный проект, где требуется большая работа по написанию кода в дополнение к имеющемуся, но проект не подразумевает большого числа посетителей.
В первом случае полезна будет, в первую очередь, глава про эксплуатацию, во втором – глава про разработку.
Примечание: В силу ограниченности объёма курса описания некоторых технологий даны в общем виде, только с целью дать направление для поиска решений проблем. Детально с такими технологиями ознакомьтесь самостоятельно.
Цель курса – помочь веб-студиям в организации работ, разработки и эксплуатации проектов. Этот курс – не столько теоретический, сколько практический, он построен на опыте разработки больших и малых, высоконагруженных и простых проектов.
Курс рассматривает вопросы создания высоконагруженных и сложных проектов без привязки к нашим продуктам. Примеры на базе платформы Bitrix Framework, приведённые в курсе, даны как один из вариантов реализации. Всё, что говорится на страницах ниже, можно применить и при работе с другими системами.
Примечание: Ознакомление с курсом будет так же полезно потенциальным заказчикам высоконагруженных проектов, так как даёт ориентиры в выборе команды для своего проекта и для оценки её работы.
Баллы опыта
В конце каждого урока есть кнопка Прочитано! . При клике на неё в вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:
уроке.
Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, добавляем новые уроки. Поэтому итоговое количество баллов курса и количество набранных вами баллов могут различаться между собой. Набранные вами баллы, в отличие от суммы баллов курса, не пересчитываются. Не переживайте!
Отличный результат – это если общее число набранных вами баллов отличается от максимального на несколько процентов.
Комментарии к урокам
| На каждой странице курса авторизованный на сайте посетитель может дать комментарий к содержимому страницы. Комментарий – не форум, там не ведётся обсуждений или разъяснений. Это инструмент для сообщения нам об ошибках, неточностях. Для отправки комментария воспользуйтесь расположенной в правом нижнем углу окна браузера кнопкой. |  |
Если нет интернета
Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox
iPhone:
FBReader
CoolReader
iBook
Bookmate
Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome
iOS
Marvin for iOS
ShortBook
Linux:
Calibre
FBReader
Cool Reader
Okular обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла – от 02.11.2021.
Курсы разработаны в компании «1С-Битрикс»
Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.