Luxoft Java Hiring Week - $2000 бонусу, круті проекти та подарунки! Реєструйся!
×Закрыть

Highload — это сколько?

Всегда хотел узнать сколько это в численном выражении можно выразить такой вот очень абстрактный термин (особенно в украинской среде) highload .

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

Так вот, 1000 пользователей в день это уже highload? А 1000000? А если 1000 сидит в ERP, а 1000000 это практически статичный сайтик?

Есть ли какая-то методология, позволяющая сказать, что вот это высоконаргруженное приложение, а вот это нет?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

О, кто поднял некротему и зачем я в ней пишу? ))))

У нас в команде на систему нагрузка до 20к RPS на хост и до 3-4M RPS на кластер (в пике). Хайлоад?

Якщо, умовно, одна хвилина простою твого сайту автоматично означає недоотриманий прибуток, можеш вважати, що це вже highload.

Большего бреда и не придумаешь

Ну, з таким підходом все, що не Facebook чи Google, highload-ом вважати не можна. Інакше де та межа, коли по одну сторону highload, а по іншу — ні?
Для когось 6000rps — highload, але завжди знайдеться хтось, хто працює з більшими об’ємами, і лише посміється з такого. Тож якшо справедливе розмиття в одну сторону, то очевидно, що це працює і в інший бік.

Те, що є highload-ом для одних, абсолютно не обов’язково є таким, для інших.

Те, що є highload-ом для одних, абсолютно не обов’язково є таким, для інших.

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

Особенно среди рубистов таких много, причину чего вообще не понимаю.

потому что у руби на сейчас — наверное самый тормозной интерпретатор.так что они быстро упираются

в численном выражении можно выразить

в численном — сложно.
качественно, просто — это когда приложение регулярно подвержено негативным эффектам от «хабраэффекта», вплоть до полного прекращения работы.

А если 1000 сидит в ERP, а 1000000 это практически статичный сайтик?

я так же аналогично спрашиваю «спецов по хайлоад», когда они пытаются мерить количеством входящих tcp запросов :)

и не только, чистые вебщики не в курсе, какие тяжелые обработки на беке инициирует всего-лишь 1 пользователь ERP. привыкли что их «сайтик на WP» работает и на 1000 одновременных пользователей на таком себе шареде, и удивляются, у-у-у, а зачем вам такие мощные сервера, у вас же там 100 сотрудников максимум, «вы наверное не умеете оптимизировать! Индексы в БД добавьте, очень помогает!»

Есть ли какая-то методология, позволяющая сказать, что вот это высоконаргруженное приложение, а вот это нет?

вряд ли.
но пару признаков может указывать что у нас highload
— какие пиковые нагрузки ожидаются как норма, во сколько раз они превышают типичные?
— какова загрузка СPU и I/O при пиковых нагрузках?
— сколько тех самых tcp запросов в состоянии поддерживать система, начиная от вебсервера?

и тогда, как ниже указали, появится признак — надо масштабироваться горизонтально — вертикально мы ничего уже не добъемся за вменяемые деньги.

1000 сидит в ERP — тоже дают ого нагрузку. но разруливается она обычно оптимизациями, разноской на разные сервера, выносом частей в отдельные сервисы, параллелизацией — сюда пишем, оттуда читаем.
то есть — нет признака:
ночью у нас 1000 пользователей, днем 10000, а вот вечером набегает полмиллиона.

но в целом, как в одном подкасте обсуждали highload, и один рассказал
... как-то один собеседующий на вопрос «а highload это сколько?» ответил:
я вам и на двух пользователях могу устроить хайлоад. Нам ответ очень понравился, взяли в итоге :)

— какова загрузка СPU и I/O при пиковых нагрузках?
— сколько тех самых tcp запросов в состоянии поддерживать система, начиная от вебсервера?

Это так же может говорить о том что железо — говно=)

Это так же может говорить о том что железо — говно=)

ну, если программист не может определить о чем это говорит, в контексте его приложения, и железо ли говно или не железо, про другие метрики он и не знает, а потому делает вывод только по этим, и т.п.
то наверное это не железо, а он такой :)

Highload — это когда вам уже недостаточно вертикального масштабирования и необходимо горизонтальное.

Количество запросов/пользователей может быть любое. Хоть один пользователь с одним запросом.

Highload — это когда вам уже недостаточно вертикального масштабирования и необходимо горизонтальное.

Mailinator?
Працював на 1 чи не домашньому ПК.

Я не в курсе, что такое Mailinator.

Хайлоад — ныне подзабытый баззворд середины 2010-х :)

Головне питання сьогодення — це вже бігдата чи все ще хайлоад?

highload — это один доклад на Highload fwdays

В 2011 я сам узнал, что такое highload. Узнал по взрослому.
4admin.info/highload-is-how-much

:)
Ну почему. Это актуально.
В IIS, например, количество потоков по умолчанию — 5. Остальные ждут ....

тьфу только понял что в некро теме отписался

Хайлоад — это относительное состояние, когда наступает время масштабироваться. Советую почитать Что такое хайлоад

Если не получается решением в лоб выдержать нагрузку — значит хайлоад.

если быдлокодерок написал поиск по ключу с квадратичной сложностью — то это у него хайлоад вдруг при деплое наступил? :)

поиск элемента с N^2 сложностью? У меня только один вопрос — КАК!!? Так как нечто более линейной сложности даже в голову не приходит.

Так как нечто более линейной сложности даже в голову не приходит.
У тебя крайне ограниченное воображение.

ну, например, каждую итерацию узнавать размер таблицы, что может быть реализовано со сложностью N

Если при ваших обьемах данных это существенно — то можно назвать хайлоадом.

По-моему термин highload стал широко использоваться благодаря одноименной конференции в москве. И по хорошему он должен называться high scalability. Но слово highload для русскоговорящих — проще.

И по хорошему он должен называться high scalability.
А почему не _high availability_?
Какая разница как сервис скейлитсо если он держит рагрузку? Горизонтально скейлить — это самый простой способ сделать highload-сервис работоспособным.
ha совсем другое
Потому что ...

Я бы сказал какой-нибудь телефонный свитч — это хайлоад, даже если он в 80-х сделан. Там тебе и СМО и статистика и горизонтальное масштабирование и все-все.

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

Термин highload к количеству пользователей никакого отношения не имеет. Есть задачи, где даже один юзер может при желании легко загрузить сотню серверов. Обычно говорят о гарантируемом времени отклика системы при определенных входных параметрах.

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

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

Каким это образом?

ну как-бы пшп код «из коробки» горизонтально маштабируемый, т.е. просто ставишь второй сервер, запускаешь, вот и все фактически

Ну дык хайлоад вот такой и есть. Большинство проблем упирается в пляски с бубном вокруг БД.

ну тут тоже есть специфика — а если база на мєйнфрейме ? танцы с бубном могут быть отложены на очень долго

Это если денежка есть. Выхлоп за бакс у мейнфреймов очень низкий.

и большинство решений заканчивается настройкой схемы один мастер — много слейвов на чтение в mySQL

Или какую нибудь клевую NoSql прикрутить

обычно через месяц в продакшене пролюбят что нибуть полезное, и давай назад на мускулечек

Это echo «Hello, World!» у вас масштабируем из коробки? Ну так это почти у всех такое. А вы залогиньте пользователя — и уже нет.

а что такое страшное, по вашему мнению, произойдет после залогинивания пользователя ? :)

сессию где хранить будете?

нну «из коробки» она либо в базе, но раз уж мы про чет сурьезное (раз уж нам надо «второй» сервер) то в memcached

ну то есть не масштабируется из коробки, ведь база она из коробки не, а уже часть решения. Что и требовалось доказать.

вы там определитесь — если у нас залогинивание без базы, то это еще больший хелловорд, который наверное и рассматривать не стоит.

ибо ващета «платформа» называется lamp , предполагается что база и вебсервер это из коробки

повторюсь: платформа lamp из коробки не масштабируема. Ибо m.

расскажите это гуглю у которых мускуль в ютубе и адсенсе

они его туда из твоей коробочки положили? Нет.

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

реплікацію то підтримує, а ваш код на php реплікацію підтримує? чи далі і писати і читати буде в той самий хост? чи модерн фрейворки і патерни теж у вас в «коробці»? :)

ну якщо замкнутися на мускуль, то можна mysql proxy підняти , яка і буде розподіляти запис і читання.
але це зовсім не відноситься до пшп :)

Взяли MySQL, установили «из коробки» и получился YouTube. Все так делают. Говно вопрос. День работы и «ютюб готов»!

Бугага! — сорі ще раз.

и вообще я больше про язык пшп — его єто state less противное, которое share nothing , из-за чего даже static переменные очищаются после отработки , приводит к тому, что изначально пишется код, без всех этих локальных кешей и т.д.
в результате сам пшп код масштабируется без проблем

да, сверический ПХП код в вакууме масштабируется неплохо.

на практике, в вакууме нет

но шардинг от языка «морды» не зависит

Ну в некоторых язычках уже есть либы которые пытаются решыть эту проблему. docs.jboss.org/...en/html_single

это то что мне не нравиться в java
фактически для двух функций
getShardDBForId
execQueryOverAllShards
написано куча кода, xml и доки и только в конце узнаешь, что впринципе оно не живое

п.с. нет, хорошо что они хоть аггрегацию и сортировку частично сделали , иначе смысла в этой либе было бы вообще 0

гы. случайно встретил ссылку варианта на пшп + mysql proxy
code.google.com/p/shard-query

Для аналитики и MPP такого гавна хватает, самое популярное опен сорс www.jboss.org/teiid. Для OLTP тема намного слабее развита, особено когда дело доходит до решардинга. На этой волне и появились всякие mongodb и прочие кассандры и hbase-ы

А після сесії в

memcached
відразу наступає dogpile-effect обхід якого «з коробки» в php нема.

для сесій dogpile-effect не наступає (вгадайте чому ? :)
а от races можуть, но воно вирішується

а умел бы хайлоад — легко отмазался бы: «-на клиенте» :P

на клиенте — то извращение

кукисы ?
а размеры как ?
и что делать с races на хроме ? ну когда хром видит сразу два кукиса с одним именем ? :)

а размеры как ?
А не шлите лишнего

Бугога! — сорі, більше сказати на цей комент нічого.

99.5% пхп-шников не в состоянии сделать масштабируемый сайт

А почему вы спрашиваете ?

Сложный вопрос?

99.5% пхп-шников
обычным php-программистом
наводит на мысль, что Вы считаете себя необычным php-программистом

Я отвечу на него если вы ответите почему из десятка людей, которые участвуют в дискуссии, вас заинтересовала именно моя квалификация

лєпо видеть человека оперирующего точными цифрами :)
но как мы ниже обсудили — сам пшп код изначально масштабируемый , затыки возникают с базами и т.д.

Нельзя так просто взять сайт, написанный обычным php-программистом и запустить на нескольких серверах. Кроме базы будут еще проблемы с сессиями. Да и с базами — если их стало несколько то надо код поменять чтобы они делали коннекты правильно. Если выбрали мастер-слейв репликацию — надо научить код делать коннект к мастеру для insert/update/delete запросов и коннект к слейву на чтение (с редкими исключениями)

какие же проблемы будут с сессиями ?

Да и с базами — если их стало несколько то надо код поменять чтобы они делали коннекты правильно. Если выбрали мастер-слейв репликацию — надо научить код делать коннект к мастеру для insert/update/delete запросов и коннект к слейву на чтение (с редкими исключениями)
я вроде приводил вариант с mysql proxy которая позволяет отправлять запросы к слейвам, а изменения данных слать мастер-базе, без изменения кода
какие же проблемы будут с сессиями ?
по умолчанию пхп хранит сессию в файле.

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

и даже если вдруг, таки используются файлы — подключаем либу , и все, код менять не надо

а изменения данных слать мастер-базе, без изменения кода
Слейв может отставать от мастера и иногда нужно делать селекты на мастер чтобы показать юзеру правильные данные. Как ты это сделаешь на уровне mysql-proxy ?

нну mysql proxy скриптуется
и опять таки — єто не проблема маштабируемости пшп, это проблема маштабируемости данных

У тебя есть реальный проект, написанный тобой, который работает по такой схеме с mysql-proxy ?

нет. не повезло — быдлокодеры успевали изобрести велосипед раньше

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

как по мне, «легкий» хайлоад начинается где-то со 100 нестатичных страничек и 1к запросов в секунду(он может и не хайлоад вовсе но уже возникает потребность тюнить), ежели 500-1000 нестатичных страничег в секунду и примерно 5-10к запросов в секунду то это уже чет похожее на хайлоад

и как вы тюните при таких объёмах?

та вроде алгоритм стандартный — профайлинг, выявление критических мест, устранение оных

На таких нагрузках надо изначально следить за загруженностью системы. Позволю себе прорекламировать свою же статью по этому поводу — habrahabr.ru/...oo/blog/149695

а 2-3 млн запросов в секунду на кластер?

алигарх в чатиге. ховайтесь пацаны

Не придумаете вы определенного числа. Банально с ростом мощностей (и вычислительных, и ИО) это число будет меняться с каждым годом, а то и быстрее.

Highload (как навык) — это скорее умение сделать так чтобы с ростом нагрузки, софт все еще работал, в идеале на том же железе (но неизменность железа совсем не обязательна).

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

Конечно, понятие highload, несколько расплывчато и зависит от деталей системы о которой идет речь, но по интуитивным ощущениям и исходя из собственного опыта, я бы начинал говорить о highload-системе с 200-300 миллионов реквестов в сутки для http или с полмиллиарда, скажем, для самописных протоколов, базирующихся на udp.

о highload-системе с 200-300 миллионов реквестов в сутки
А тут jobs.dou.ua/...vacancies/2335 пишут: «работать в настоящем hi-load проекте (более 5 млн хитов в сутки)»
Так шо хайАПлоад бывает разный :)

Prom еще не самый худший пример UA-хайлоада.

Prom еще не самый худший пример UA-хайлоада.
А я и не говорил что "худший"/"плохой«. Просто «все относительно ребята».

У ДОУ сегодня был хайлоад после публикации зарплатного отчета :(

Так ведь радоваться же надо :)

Пользователей было не очень много онлайн — порядка 250, но из-за того, что какой-то параметр (типа макс. кол-ва подключений) был неправильно настроен, сайт где-то час работал с перебоями.

Действительно, не повод радоваться.

А так на ДОУ наибольший всплески посещаемости (когда 800 человек онлайн) после публикации новостей типа «Макси-шоу в компании ...», но тоже радости мало.

500млн в сутки? Это ваще не нагрузка даже. У нас в команде на систему нагрузка до 20к RPS на хост и до 3-4M RPS на кластер.

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

Ну была промышленная системка на Delphi + Firebird, там сейчас более 3000 запросов к базе в секунду (в основном от датчиков). Такая вот красивая трехзвенка.

ну так можете мерять корону хайлодиста. Основной массе руби хипстоты до такой нагрузки еще расти и расти :)

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

немножко придираюсь ... но большинство датчиков в промышленных системах в нашей стране запросы к базе самостоятельно не умеют генерировать.... так что наверное это приложение на Делфи 3000 переменных в секунду в базу складывало ? Ну или несколько приложений.... ;) ?

На датчиках висели микроконтроллеры, которые по udp обращались к серверу приложений на Delphi (middleware) и уже приложение работало с базой. Плюс терминал оператора, который тоже работал с базой.

да, хорошая система .. архитектура в принципе классическая и как по мне очень удачная , но все же подключений к базе немного ... хотя для Firebird 3000 записей в секунду достаточно хорошая нагрузка.

Для меня тоже термин Highload не совсем понятен :) точнее я общался с людьми которые делают очень большие проекты .. но там ....как уже писали .. кластера , кеши многоуровневые и тд и тп ... вообщем расплывчатое очень понятие сейчас... наверное он правда для всех технологий разный

оффтопик: А база быстро росла ? За большой период там данные хранили ?

оффтопик: А база быстро росла ? За большой период там данные хранили ?

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

действительно что-то переклинило

Подписаться на комментарии