Что такое highload?

buzzword

может быть имеется в виду, что надо пахать в хайлоад режиме?
а если не умеешь так, то ты не конкурентоспособен :)

Это способность выдержать сервером производительность более одного запроса в секунду в полном объеме: сессии, БД, формы, таблицы, сжатие, https ...

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

дооо, а когда надо будет распарсивать эти текстовые логи, вот тогда и будет вам такой лоад, что хая долго еще не будет)))

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

дооо, а когда надо будет распарсивать эти текстовые логи, вот тогда и будет вам такой лоад, что хая долго еще не будет)))

Не проблема. elastic/hadoop/pig/swarm. Если ничего этого нет, то аналитичиские запросы к RDBMS нагнут окончательно те жалкие крохи, что еще остались после записи логов.

Вот ТС, видишь, товарищ outsider вообще не в теме и хайлоада не нюхал.

канеш не видел, нафиг мне такой хайлоад

Это как bigdata, только highload.

Умение масштабировать распределенные системы

Везде и у всех нынче highload.

Это нынче у всех HR-ов с головой полный хайлоад.

Везде и у всех нынче highload. Требуются девелоперы, умеющие в highload

в 99% случаев это означает «хоть иногда вспоминать про производительность того, что накодил и уметь найти bottleneck». ИМХО. ИЧСХ, большинство не умеет.

А что такое по-вашему highload?

когда утилизация сетевых каналов и ресурсов железа >50%, а с точки зрения пользователей всё работает быстро

// точка зрения с дивана. в highload не работал

когда надо будет распарсивать эти текстовые логи, вот тогда и будет вам такой лоад

Не переживай, ты в этом случае будешь говорить «до 10% отказов решение проблемы не стоит поиска», или «логи не содержат информации о проблеме, т.к. их писать не хватает ресурсов».

только это к архитекторам а не девелоперам вопрос уже

Java, python, php, etc

логировать либо в базу либо в файл

залогинься и не позрь анонов

Это когда нет денег вертикально масштабироваться и купить мейнфрейм.

Вместо этого отключаются логи и включаются костыли.

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

однажды придется масштабироваться горизонтально

Вовсе не факт.

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

залогинься и не позрь анонов

Ты хочешь поговорить о событиях, тебя что-то гнетет? Спрашивай свои вопросы.

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

ППКС!

Какой тред! Какой бальзам в уши!

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

highload подразумевает высокую нагрузку. Высокая нагрузка подразумевает горизонтальное масштабирование. Т.е. требуются программисты с опытом разработки горизонтально масштабирующихся систем. Я это так понимаю. Естественно чем больше серверов было в твоём проекте, тем больше нетривиальных проблем ты видел и имеешь опыт их предвидения и решения.

ИМХО. Высокая нагрузка совсем не подразумевает тонны серверов. Тонны серверов подразумевают говнокод (или кучу слоев абасракции) ворочающийся в один момент времени.

ИМХО. Высокая нагрузка совсем не подразумевает тонны серверов. Тонны серверов подразумевают говнокод (или кучу слоев абасракции) ворочающийся в один момент времени.

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

Не, погоди, еще одно есть подразумевание кучи серверов — необходимость обработки за короткое время большого кол-ва данных, которые нельзя фрагментировать, т.к. они (или их представления) целостносны.

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

Не согласен. Сервер мощьностью *100 не нужен. Так же не нужны и 100 серверов (если только не... я уточнил в предыдущем сообщении).

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

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

Надо позвать erzent-а он один знает что такое highload

black rice highload

Что такое highload?

Модное хипстерское словечко для гомикообразных обсосков с зашкаливающим ЧСВ.
/thread

ИЧСХ, большинство не умеет

подтверждаю. ведь большинство считает, что железо нынче дешевле разработчиков

Так правильно считают. Погромисту плати Nк в месяц. А железку купи один раз в ту же сумму. Хайдоад в том виде о котором мы говорим — это экономически выгодный буллшит.

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

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

Это когда увеличение количества серверов в N раз даёт прирост производительности в N раз. И так можно почти неограниченно наращивать производительность без переписывания системы с нуля.

мы в общем то не про системные логи разговариваем, а

«логи не содержат информации о проблеме, т.к. их писать не хватает ресурсов».

это уже на грани фолла и к HL никакого отношения не имеет

не про системные логи

И я о них же.

это уже на грани фолла

Генерация логов уровнем выше, чем «ой #$%#$%!» часто обеспечивает значительный рост нагрузки на выч. ресурсы. Если в «#$%#$%» удаётся закодировать достаточно информации для анализа, и такой «ой!» генерится только по существенным поводам - ОК, вам повезло.

к HL никакого отношения не имеет

У LL это несущественно - там можно себе позволить логи уровня trace, и редко возникает вопросов «какая из этих 31416 операций нас интересует?». Потому, думаю, что имеют.

Но моя выборка нерепрезентативна; возможно в «правильном» HL с этим научились бороться, а я просто ещё не видел как. Но подобная оговорка применима почти к любой «форумской» ситуации, я её, обычно, опускаю ради оптимизации энтропии. Ивините, если это кого-то вводит в заблуждение.

По моему опыту HL начинают интересоваться, когда «мы увеличили количество серверов с 10 до 50, существенного прироста производительности не заметили, предлагаем увеличить количество до 100», ходят с матрами «premature optimization is the root of all evil» и «и 1 программист за 100K не лучше 5 программистов за 20K». После лекции про оптимизацию на каждом этапе проекта объявляют еретиком, разговаривают на каком-то птичьем языке. Патчи на оптимизацию параллельной работы (убрал пару лишних синхронизаций), позволяющих влезть в текущую конфигурацию (это CRM на 350 менеджеров, а не на 10000, какого хрена), не берут, так как «не соответствуют архитектуре проекта», с архитектором поговорить нельзя, так как он занят на другом проекте. В результате 2 месяца с неустойками (10% бюджета швах). Зато все в костюмчиках при галстуках. Хоть заплатили. Теоретики, блин.

«до 10% отказов решение проблемы не стоит поиска»,

Ого, эти слова надо выучить.

Железо всегда было дешевле софта.

Это когда увеличение количества серверов в N раз даёт прирост производительности в N раз. И так можно почти неограниченно наращивать производительность без переписывания системы с нуля.

Нa урок мaтемaтики приходит учительницa со стрaшнейшего бодунa...
- Дети. . .иккк..., что мы проходили нa прошлом уроке?
- Геометрическую прогрессию, Мaрь Ивaннa.
- Ну, и скaжи-кa нaм, Петровa, что же тaкое, этa геометрическaя прог. . иккк. . .рессия?
- Геометрическaя прогрессия - это ...когдa кaждый следующий член больше предыдущего в двa рaзa!
- Ос-тa-вь свои девичьи фaнтaзии ...Пет-ро-вa...! 

Кеширование забыл.

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

Highload это когда на сервис обслуживает Х обезьян, а Х равно тому числу, при котором большинство обезьян скажет «вау».

В моем понимании highload - отношение пиковой производительности сервера к его (средней) нагрузке. И на P-1 можно организовать highload.

Соответственно «девелоперы умеющие в highload» должны уметь в оптимизацию как минимум.

HR'ам которые говорят highload не объясняя задачу адекватно можно дать щелбан.