Что такое highload?
Очень часто встречаю термины «высокие нагрузки», «высоконагруженные веб-приложения», «highload» и т.д. Хотелось бы узнать количественную (абсолютную или относительную) характеристику высоких нагрузок или же методику её расчёта (с параметрами).
- Вопрос задан более трёх лет назад
- 42481 просмотр
Комментировать
Решения вопроса 1
для меня, в разрезе веб-приложений, хайлоад начинается с сотен запросов в секунду. Запросов не к кешу статического контента, а именно к приложению. Это так, грубо.
Ответ написан более трёх лет назад
Нравится 6 2 комментария
а вообще, это очередной затасканный buzzword, который может значить все, что угодно.
присоединяюсь к этому ответу — от себя добавлю, что hilioad-приложение прежде всего должно быть изначально ориентировано на горизонтальное масштабирование, но и соответственно пара сотен запросов в секунду его не должно пугать.
Ответы на вопрос 10
Highload обычно употребляется в смысле — «умение горизонтально масштабировать веб-проект до любого теоретически достижимого числа клиентов».
По численным именам по мне лучше использовать более конкретные имена, к примеру устоявшееся C10K problem, или «как работать с 10000 одновременные коннектами пользователей» на комп. При работе с торрент-анонсером, такая проблема, к примеру, возникала.
Ответ написан более трёх лет назад
Нравится 6 2 комментария
ну торрент трекер не совсем правильный пример. Около 120000 анонсов выдерживал 2х процессорный сервер на Оптеронах и паре гигов памяти с помощью XBT.
да, мы тоже допилили и использовали xbt — благо он использует libevent и проблема с C10K в нем учтена.
120K анонсов в секунду? это круто. у нас была поменьше нагрузка 3-5K анонсов в секунду. да и машинка послабее
Highload — упереться во все ограничения сразу.
Ответ написан более трёх лет назад
Комментировать
Нравится 5 Комментировать
Highload — это когда традиционных подходов и стандартных решений уже не хватает.
Ответ написан более трёх лет назад
Нравится 5 2 комментария
Каких традиционных? Типовая трёхзвенка (балансер->ферма WEB-серверов->DB-кластер) это традиционный подход, или нет?
Смотря для какой задачи. То, что вы перечислили может использоваться типичным шаред-хостингом, и они не будут считать, что занимаются высоконагруженным проектом.
А для сайта веб-магазина, скорее всего это будет уже называться хайлоадом, ибо типичному веб-магазину не нужна груда веб-серверов и кластер БД.
Нет ни методики ни чисел. Highload — это название состояния инфраструктуры, которая требует того, чтобы ее оптимизировали и масштабировали. Т.е. это просто описание состояния. Например, что такое уставший человек? Один может пробежать 10 км и будет уставшим. Другой уже после 500 метров и станет уставшим. Они оба уставшие, а параметры разные. Так и для ресурсов. Советую почитать — Что такое highload?
Ответ написан более трёх лет назад
Комментировать
Нравится 3 Комментировать
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
ее нет. Но слово и в правду модное. Таким образом каждый разработчик сам для себя решает что для него есть хайлод.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Просто люблю качественно работать
НУ если у вас есть миллион клиентов то вас смело можно звать хайлоадом 8)
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Влад Животнев @inkvizitor68sl
Linux-сисадмин с 8 летним стажем.
200к-300к RPS к сервису — вполне себе хайлоад.
Ответ написан более трёх лет назад
zizop @zizop Автор вопроса
А если 100 rps (100K хитов в сутки), это уже не хайлоад? Пытаюсь найти ту-самую черту 🙂
Ну вот где-то так… как-только появляется нужда в масштабировании, так уже и хайлоад. Миллион запросов в сутки для типичного сервиса.
Обычно это модное слово применяют когда текущее приложение/окружение перестает справляться с моментальной нагрузкой.
Но в реальности означает немного другое и конкретные цифры сказать трудно, все относительно.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Программист, автолюбитель
По мне хайлоад это когда не хватает одного физического сервера для обслуживания клиентов. раньше хайлоад был 20 запросов в сек (без nginx), сейчас уже пожалуй и 100 запросов в сек не хайлоад (c nginx)
Хайлоад это когда начинаются пляски с маштабированием управлением администрированием кешированием.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- WordPress
- +1 ещё
Как вывести текст перед рейтингом на WordPress?
- 1 подписчик
- 17 минут назад
- 10 просмотров
HighLoad++ для начинающих
Чтобы рассказать, что такое highload, надо для начала определиться с термином. При попытке «разгадать» сам термин, начнем, естественно, с прямого перевода – это высокая нагрузка.
Терминология
53.328*10^9 запросов в секунду – вот такую цифру я выписал из википедии. Хватит ли нам столько – непонятно, но это у нас средний CPU сейчас столько делает.
Если подходить более реалистично, то надо определиться с цифрами. Например, один запрос в секунду – это нагрузка явно не highload, любой сервер, вроде бы, справится. Но, например, если он перекодирует видеоролики, то тут может наступить highload.
Соответственно, я определяю высокую нагрузку как нагрузку, с которой железо не справляется по какой-то причине.
Когда у нас происходит высокая нагрузка, начинают вести речь о highload-е – когда мы достигаем каких-то технических ограничений, т.е. у нас кончается что-нибудь – CPU, память. Я еще вынесу хранилище отдельным пунктом, потому что для веб-серверов хранилище обычно – это какой-то внешний элемент.
Дополнительно мы сталкиваемся еще с такими трудностями – сейчас уже менеджеры перестали, но лет 5-7 назад, когда они покупали новый сервер, а вы через некоторое время говорили «нам этого сервера не хватает, нам надо больше», они удивлялись: «мы вам купили самый крутой компьютер на свете, а вы умудрились его тормознуть?». Сейчас они уже не удивляются, но вопрос недоиспользования «железа» так и остается самым основным. Т.е., если вернуться к тому, что средний процессор сейчас способен обработать 53 млрд. операций в сек., то объяснить людям, почему тормозит, очень сложно. Ну и трудности масштабирования, все эти проблемы, которые происходят с высокой нагрузкой, они сводятся к одному термину – архитектурные проблемы в вашем проекте.
Цикл выполнения одного запроса
Для иллюстрации рассмотрим типичный веб-сервер, написанный неважно на чем – на Perl, Python, Ruby. Берем стандартный framework, делаем веб-сервер, пишем форум, доску объявлений и т.д. Задачи одного цикла этого сервера сводятся к следующим пунктам:
- запросы сети читаются;
- парсятся;
- отправляются запросы в БД;
- формируются ответы;
- отправляются клиентам.
Т.е. если говорить о традиционной реализации (apache, например), то все это сводится к тому, что на одну сессию выделяется один процесс или один тред. Ну, или если вернуться к определению «highload» как к нагрузке, с которой не справляется железо, то что они в этой архитектуре могут сделать?
Они могут увеличить число процессов на один цикл или тредов, которые работают, либо масштабировать уже по серверам, т.е. вводить в строй сервера.
Вот, к примеру, рассмотрели одну страничку одного проблемного сервера в реальных измерениях. У нас получилось следующее: примерно на 100 запросах в секунду возник highload. Первое, что сделали, – это увеличили число процессов в работе, т.е. было 8 процессов, сделали 20, потом 30 и т.д. Временно помогло, но на 150 запросов в секунду опять начались проблемы. Что делать? В этот момент прибегают менеджеры и говорят, что сходили на конференцию «Highload», где им рассказали про всякие мега крутые технологии, которые они сейчас купят и все перепишут. Тут их останавливают люди, которые говорят, что они 3 года над этим работали и переписывать это надо тоже 3 года. Что делать? Добавлять второй сервер тоже не всегда просто.
Лечение любой болезни начинается с постановки диагноза, т.е. для начала измерим хотя бы температуру, а потом будем делать выводы.
Мы взяли одну страничку веб-сервера, которая тормозит и которая была довольно популярна, провели измерения и получили следующие RPS:
- чтение запроса из сети – 15К RPS
- парсинг запроса, контроллер – 150К RPS/CPU
- запросы к хранилищу – 60К RPS
- формирование ответа – 100К RPS/CPU
- отправка ответа клиенту – 15К RPS
Если мы все эти цифры начинаем друг с другом складывать, то получается расчетная производительность нашего сервера 6000 RPS.
Но менеджеры продолжают бегать – проблемы-то при 150, что делать?
Начинаем смотреть на все бенчмарки, которые мы сделали. И видим – если хранилище придвинуть к серверу максимально близко, а еще клиента посадить прямо за сервер, то, вроде бы, становится хорошо.
Резюме ситуации таково: мы работали над сервером несколько лет вот в этой парадигме, программировали, а ее сейчас менять очень сложно, но мы видим, что все части нашего сервера работают с достаточной производительностью, которой еще на несколько лет вперед должно хватить.
Профайлинг
Стоить начать смотреть уже не на бенчмарки, а на профайл, т.е. на то, сколько времени какой процесс занимает.
В IT-мире все идут по такому пути, на котором открывают какие-то IT-закономерности и этим закономерностям в реальной жизни есть какая-то аналогия. Я предлагаю аналогию с обувным магазином – когда вы приходите в обувной магазин, то на вас сразу набрасывается менеджер, который с вами бегает туда-сюда, вы ходите, смотрите – вот эта обувь мне подходит/не подходит, он вам может сбегать на склад, принести и т.д.
Если сравнить списки слева и справа, то они очень похожи:
Если вернуться к серверу и перейти от бенчмарков к профайлу, выписать время каждого пункта, то у нас получатся следующие цифры:
Это реальные цифры, они просто округлены.
В итоге у нас после просмотра результатов профайлинга получится, что код наш выполнялся 17 мкс, а чего-то ждали – например, ответа от БД, сети и т.п. – 156 мкс. Возникает какой-то дисбаланс – наш код выполняется всего 10% времени, и при этом все тормозит, нагрузка – 30. что делать?
Когда все это проходили, написали вот такую потрясающую программу, которая имитирует высокую нагрузку:
Эта программа ничего не делает, кроме sleep-ов, т.е. на месте каждого действия у нас sleep на такое же количество мкс, как было замерено. Если, кстати, говорить о реализации usleep, то в linux, начиная с ядра 2.6, usleep реализован реальным усыплением процесса, т.е. до этой версии еще можно было предъявить претензии к реализации, то сейчас это реальная модель вашего веб-сервера.
Что же получилось? Эта замечательная программа спокойно очень грузит процессор где-то на 15%, при этом ничего не делает. Когда же мы запускаем таких «воркеров» примерно столько же, сколько в apache, то получаем ту же самую нагрузку на хосте, те же 20-30 единиц «out average».
Если вернуться к нашему серверу, то каждая отдельная часть имеет хорошую производительность, но что же нам делать? Раз каждый «кирпичик» удовлетворяет нас по скорости, то нам просто надо взять и пересобрать эти «кирпичики» в каком-то другом порядке, т.е. просто взять и реорганизовать код.
Событийно-ориентированное программирование
Переходим к событийно-ориентированному программированию, т.е. начинаем читать, что у нас происходит в мире, что люди думали по этому поводу и натыкаемся вот на такие вещи:
Очень хорошее высказывание, рекомендую над ним подумать. Компьютер – это конечный автомат, соответственно, когда компьютер реализует парадигму тредов, он сводит все к конечному автомату. И, если люди говорят, что нужно избавляться от тредов, надо от них избавляться. Ну, еще заодно и от процессов.
Если мы вернемся к аналогии с магазином, то очевидно, что если в магазин обуви придет сразу 100 покупателей, то никаких менеджеров не хватит, и надо будет что-то реорганизовывать. И в реальной жизни люди давно справились с задачей высокой нагрузки в магазинах, например, продуктовый магазин устроен совсем по-другому, чем обувной. Т.е., всех клиентов ставим в очереди, и продавец обслуживает всех без простоя. Надеюсь, эта аналогия всем понятна.
В IT-мире этот «продуктовый магазин» представляет собой так называемую машину событий – исполнитель заявляет о готовности выполнить задачу (как в McDonald’s – «Свободная касса!»), как только «покупатель» подходит, его сразу обслуживают, а если ему нужно подождать, его ставят в другую очередь ожидающих чего-нибудь, например, со склада. В IT-мире реализация продуктового магазина сводится к тому, что исполнитель подписывается на то, что он выполнит задачу, т.е. регистрирует callback, а выполнение задачи – это, собственно, вызов callback-а и ожидание – это возврат машине событий управления путем возврата из callback-а.
Если мы возьмем не весь сервер, а просто для эксперимента перестроим проблемный веб-сервер на эту парадигму, то получится, что нам придется заменить следующие вещи: интерфейс веб-сервера, интерфейс БД и интерфейс с сетевыми вещами, если они есть.Мы увидим, что производительность нашего сервера выросла, как минимум, в 10 раз после такой реорганизации. Среднее время ответа тоже возросло. При этом одного процессора стало хватать на то, чтобы обслуживать нагрузку в 10 раз большую, чем раньше.
- сохранение контекста между callback
- ветвление
- обработка исключительных ситуаций
Самое критичное – это то, что во всех проектах обычно бизнес-логику строят около БД, т.е. выбрали данные, что-то посчитали или внутри БД или рядом с выборками и поэтому все эти условия типа «если клиент предпочитает зеленый цвет, то его направить туда, а если красный, то сюда» – они все около БД находятся и поэтому переписывать все запросы в БД на callback-е это практически приводит к тому, что 90% проекта будет переписано.
Но нам это не подходит и поэтому нужно попытаться объединить плюсы обувного магазина с плюсами продуктового. А в продуктовом магазине менеджер не простаивает. В нашем случае менеджер – это процессор.
Green threads
Если вы смотрели на ту потрясающую программу со sleep-ами, то я не коснулся того, почему она тормозила, но сейчас расскажу. Планировщик процессов в ОС – это вещь очень тяжелая. Во-первых, при каждом переключении процессора происходит переключение контекста очень тяжелого – процессы изолируются друг от друга, во-вторых, планировщик пытается синхронизировать эти переключения с частотой 1000Гц. И здесь проблемы есть по скорости. Соответственно, если мы возьмем плюсы планировщика и объединим их с плюсами event-машины, то мы как бы объединим обувной магазин с продуктовым. И для этого пишем свой планировщик. Эти планировщики люди часто называют fiber-ами или green tred-ами – во многих языках есть, я коснусь этого позже.
Основной API сводится к тому, что процесс можно создать и из процесса можно передать управление планировщику, а прервать процесс нельзя, потому что невытесняющая многозадачность. Т.е. мы отказываемся от всех «плюшек» процессов ОС в угоду быстродействию.
Теперь, если мы интегрируем планировщик с машиной событий, то получим примерно такую структуру кода на каждое событие:
т.е. мы подписываемся на событие и «усыпляем» текущий процесс, а событие будет – и процесс продолжается, т.о. программа становится такого же линейного вида, как она и была, т.е. запросили БД, сравнили результаты с каким-то эталоном и пошли по веткам влево или вправо – вернулись к почти традиционному виду программы.
Что у нас получается в веб-сервере? В него нам пришлось добавить машину событий, библиотеку fiber-ов, переписать все интерфейсы, на которых возникало ожидание чего-то – это, как правило, интерфейсы с веб-сервером, с БД и с сетью, если она есть.
Ну, и получается, что переписывание в такой парадигме сводится к тому, что мы пишем враппер над БД, враппер над веб-сервером и над сетевыми обращениями. В общем проекте получается, что переписывается всего около 5% кода.
Языки и технологии
Если говорить о библиотеках на языках, то на Perl просто прекрасная библиотека Coro – она реализует концепцию fiber-ов – легкого планировщика – плюс машина AnyEvent. На Python – fibers и twisted, а на PHP5.5 появился, наконец, оператор yield, fiber. Т.е. все эти парадигмы становятся доступны и php-программистам, но я пока в opensource-проектов, реализующих fiber-ы, не нашел.
Как только мы открыли для себя эту технологию, то сразу бросились все, что у нас тормозило, переписывать в такой парадигме. Доходило до смешного – люди простые циклы for i от 1 до 10 стали переписывать в асинхронной форме, т.е. в каждом цикле передавать управление планировщику – т.е. ничего, что мы 1 запрос от пользователя обрабатываем 5 секунд, но зато мы можем 10000 пользователей в секунду обработать!
Существуют framework-и, которые под эту парадигму программирования написаны. Например, Node JS – изначально асинхронный веб-framework, т.е. разработчики изначально думали об утилизации одного процессора по максимуму, но они отказались от парадигмы fiber-ов. Хотя, возможно, скоро они к ним придут.
Ну и, наш Tarantool. Он представляет собой сейчас полноценный application-сервер, который полностью реализует и предоставляет пользователю эту парадигму программирования, т.е. fiber-ы и event-машину. + «на борту» имеет неплохую БД в 2х ипостасях – БД в памяти и на диске. Кроме этого, серия библиотек, которая реализует неблокирующие сокеты, http-серверы, очереди и можно самим писать все, что хочется.
Общие недостатки этого подхода выясняются при попытке его повсеместного внедрения – на традиционных языках программирования этот подход позволяет утилизировать только один процессор, а нагрузка растет, и рано или поздно приходим к масштабированию – и по CPU и по хостам.
Уже давно существует язык Erlang, который позволяет все эти проблемы решить, однако имеет очень высокий порог вхождения, т.е. очень трудно объяснить программистам, что в языке программирования нет понятия «переменная», например.
Недавно появился Go – у него более низкий порог вхождения, потому что у него более традиционная парадигма программирования.
В свое время мы на этой парадигме программирования написали в свое время крупнейший бэкенд для Яндекс.Такси. У него сейчас примерно такая нагрузка – более 20000 водителей постоянно шлют свои координаты, более 1 млн. заявок в месяц, т.е. общее количество информации и трафика – большое. Проект реализован просто на Perl-овых скриптах (Coro+AnyEvent) и множество очередей (клиентов перед менеджерами) стоят на Tarantool-е, т.е. с помощью Tarantool-а реализуем очереди. И большое дисковое хранилище на PostgreSQL. Этот проект реализует у нас мобильное приложение клиента, водителя, диспетчера и т.д. и все это размещается всего на 2х серверах Hetzner-а, при этом один из них резервный.
Когда мы эту технологию освоили, все поняли, что мы очень крутые программисты.
Highload: что это такое
Если вы заинтересовались веб-разработкой, то наверняка уже успели столкнуться с таким понятием как highload, что в дословном переводе звучит как «высокая нагрузка». Это достаточно относительное понятие, ведь его нельзя измерить скоростью работы интернет-ресурса или количеством запросов, ведущим на него. Такого понятия, как «средний сайт», на показатели которого можно было бы ориентироваться, вовсе не существует. Все онлайн-порталы индивидуальны. Даже одинаковое количество запросов, ведущих к ним, может оказывать абсолютно разные нагрузки на те или иные ресурсы.
Вас как веб-разработчика должно интересовать не то, что же представляет собой Хайлоад, а то, когда обычный проект переходит в высоконагруженный, то есть в highload.
Когда можно говорить, что наступил high load?
Если вы заметили, что ваша текущая инфраструктура не совсем справляется с возлагаемой на нее нагрузкой, то в этом случае можно говорить о наступлении highload. Для VPS на 128 Мб это может быть уже 10 запросов в секунду. Для некоторых сайтов данных показатель может достигать и 10 000 запросов. Но важно не это, а то, необходимо ли вам приступать к оптимизации и увеличению масштаба своей инфраструктуры или нет. Чтобы убедиться в наличии данной проблемы, необходимо провести диагностику. У вас всегда под рукой должна быть проверенная система мониторинга. Периодически пользуйтесь ею при разных нагрузках. Это позволит вам не упустить оптимальный момент для масштабирования. Достойно зарекомендовали себя такие системы отслеживания и мониторинга трендов работы серверного оборудования, как Munin, Zabbix, Nagios.
Обратите внимание на наличие симптомов приближения момента highload:
- замедленная или практически отсутствующая загрузка страниц;
- система периодически выдает случайные ошибки;
- от web-сервера поступают оборванные соединения;
- содержимое загружается не полностью, например,
- отсутствует часть картинок;
- активность целевой аудитории заметно снизилась.
Система аналитики (Google Analytics, либо Яндекс Метрика) также позволит установить то, как влияет состояние вашего сервера на пользователей.
Что предпринять?
Как и везде, искоренить проблему можно только после того, как будет установлена причина ее возникновения. Поэтому следует проверить:
- Web-сервер. Если ваш интернет-сервер настроен корректно, то он сможет перенять на себя существенную долю нагрузки на железо. Пользуетесь Nginx, убедитесь в грамотности его настройки. Если на сайте имеются постоянные картинки либо файлы, которые вы не будете менять и корректировать, следует обратить внимание на то, настроен ли Nginx для отдачи файлов. Если вы пока еще не пользуетесь этим веб-сервером, то задумайтесь над тем, чтобы все же перейти на него. Даже если вы не обнаружили никаких проблем на сервере, все равно проведите оптимизацию клиентской части. Благодаря этому вы сможете сэкономить внушительное количество ресурсов, обеспечив тем самым достойную скорость работы портала для пользователей.
- MySQL. Достаточно часто проблему можно обнаружить в базах данных. Изначально следует убедиться, что настройки MySQL в максимальной степени соответствуют именно вашим нуждам. Включите в базе данных лог медленных запросов и проанализируйте их, используя соответствующие инструменты.
- PHP. Проблемы, связанные с языком программирования, встречаются не особо часто, но все же исключать их нельзя. Проанализировав работу приложения, вы сможете установить проблемные места. Приложение XHprof позволит вам оперативно и с удобством провести профилирование.
Надо ли заранее готовиться к хайлоад?
Если вы серьезно взялись за разработку и продвижение своего сайта, постоянно расширяете и обновляете его, значит, вы должны быть готовы к тому, что в определенный момент он станет высоконагруженным, то есть вы перейдете в режим highload. Чтобы это не оказалось для вас неожиданностью и не приостановило на время работу ресурса, воспользуйтесь такими советами:
- Убедитесь в том, что вы сделали все необходимое на этапе базовой оптимизации. Воспользовавшись VPS, вы сможете всего за 10-15 минут получить заметный прирост в производительности.
- Система мониторинга должна быть запущена с первого дня работы сайта. Она позволит вам всегда быть в курсе происходящего с вашим сайтом.
- Не занимайтесь предварительной оптимизацией, ведь сложно предугадать, что будет актуальным завтра. Вы просто можете потерять время и усилия на ненужные действия. Основной акцент сделайте на гибкость системы, что позволит вам легко и оперативно вносить в нее соответствующие изменения.
Последний совет: изучите ошибки, которые чаще всего допускают веб-разработчики в данном вопросе. Это позволит вам избежать их в собственной практике.
Разработка highload-проектов
Кроме обычного потока пользователей у каждого интернет-магазина или web-сервиса бывают особо напряженные дни. Классический пример для e-commerce – черная пятница. Мы делаем проекты, которые не только успешно справляются с ежедневными нагрузками, но и легко масштабируются под пиковые нагрузки.
Под highload понимается устойчивость интернет-проекта к высоким нагрузкам. Это не какой-то универсальный кусок кода, который достаточно добавить на сайт, чтобы он начал «летать». Это настройка архитектуры сайта: работа с базами данных, сервером, использование современных технологий и языков программирования.
Что такое highload?
Для highload-проектов предлагаем микросервисную архитектуру. При таком подходе проект состоит из множества независимых сервисов, которые общаются между собой посредством api. Это несколько дороже в поддержке, чем единый «монолитный» web-сервис, но для больших проектов дает ряд бонусов:
Кроме того, система, которая разделена на независимые друг от друга микросервисы, по умолчанию будет более устойчивой. Так как в этом случае, при возникновении сбоя в каком-либо сервисе, сайт в целом будет продолжать нормальную работу.