Вхід і реєстрація
Навчання · 16 вересня 2013, 10:53 9097
Дмитрий Шемет, iOS Dev

Высоконагруженные системы — с чего начать?

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Вкратце:
Что-то меня заинтересовала данная тематика — высоконагруженные системы, всякие параллельные вычисления (на GPU или ещё чего).
Однако я не пойму, есть ли у нас где такие задачи и что нужно знать.
Собственно вопрос в том, куда копать и есть ли на нашей родине такие проекты. Сидеть долго дома и что-то писать своё не хочу, так как реальный опыт то не там :)

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

О себе: 2.5+ опыта под ObjC + C.

Теми: highload, Junior
👍ПодобаєтьсяСподобалось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
Artem Maschenko CEO в PayJoy 19.09.2013 05:40

Совсем недавно из нашего стартапа образовалась небольшая библиотека (на ruby) помогающая в масштабировании API — rodent.

Принцип ее довольно простой.

Есть HTTP сервер который работает как proxy — переводит каждый запрос в JSON, отправляет его в определенную очередь (по route) и ждет ответа (асинхронно) от микро-сервиса. Микро-сервисы — это небольшие серверы (разделенные по функционалу) которые слушают нужную очередь, обрабатывают их и возвращают ответ для proxy. Каждый микро-сервис работает независимо и может быть запущен Nое число раз — все сообщения балансятся между ними по роуту.

Зачем?
1. Мы делим наше API по функционалу — если вдруг будет найдена ошибка в одном сервисе и он упадет, то все остальные будут работать.
2. Т.к. все сообщения у нас работают через AMQP протокол — мы можем быстро переписать отдельные части нашего API на другие языки для оптимизации (например Go).
3. Мы получаем бесплатный Hot-Reload.
4. Микро-сервисы могут запускаться на разных машинах и в любых количествах — довольно быстро можно распределить нагрузку.
5. Критические баги довольно просто изолировать — просто вырубаем нужный сервис на время.

Работает все на ruby (мы собираемся часть наших сервисов переписывать на Go) и выглядит пока немного сыровато (мы пока не в production). Если есть желание помочь с библиотекой (например добавив клиента для Go/Python/че-нить еще) — welcome.

Відповісти
Підтримати
reality_hacker 19.09.2013 07:03

Перепишите все на джаве и все будет работать на 2-ух серверах (для реданденси) с загрузкой проца на 10% без всяких микросервисов и queue

Відповісти
Підтримати
Artem Maschenko
Artem Maschenko CEO в PayJoy 19.09.2013 07:13

Причем тут Java? Ты кажется совсем не понимаешь о чем идет речь...

Відповісти
Підтримати
reality_hacker
reality_hacker 19.09.2013 07:15

Это не важно о чем идет речь, если переписать на джаве, то все это станет не нужно. Неужели опыт твитера и square ничему не научил людей?

Відповісти
Підтримати
Artem Maschenko
sensei 20.09.2013 03:11

думаю им до твиттера далеко

Відповісти
Підтримати
reality_hacker
sensei 20.09.2013 03:46

дополню риал_хакера
Два сервера обслуживают основную часть клиентов
В случае сбоя один сервер может полностью подменить другой
Glassfish берет на себя планировку нагрузки, учитывая многоядерность системы

Відповісти
Підтримати
Artem Maschenko
Artem Maschenko CEO в PayJoy 20.09.2013 04:14

Дело не только в распределении нагрузки.

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

PS: Goliath сервер написаный на руби может обрабатывать более 2500 запросов в сек. Язык тут абсолютно не важен.

Відповісти
Підтримати
sensei
reality_hacker 20.09.2013 04:30

А в чем именно преимущество в простоте управления 100500 мелких серверов перед двумя обычными?

Відповісти
Підтримати
Artem Maschenko
Artem Maschenko CEO в PayJoy 20.09.2013 04:45

Отвечу вопросом на вопрос. А почему весь код не написать в одном файле?
PS: Плюсы я уже изложил выше.

Відповісти
Підтримати
reality_hacker
reality_hacker 20.09.2013 06:16

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

Відповісти
Підтримати
Artem Maschenko
sensei 20.09.2013 04:41
Язык тут абсолютно не важен.
Вы хотите сказать что руби вытянит нагрузки типа моллома на одном хосте?
а как же поднять файлик и распарсить или я что-то упустил?
Відповісти
Підтримати
Artem Maschenko
Artem Maschenko CEO в PayJoy 20.09.2013 04:52

Да, может

Вкратце, цитирую:
> Our load tests showed that our new Goliath endpoint was handling 4,500 reqs/sec with a 200ms avg. response time. Holy crap! This knocked the socks off our previous go ’round by an order of magnitude — even running on equivalent hardware. Now granted... 200 ms is still not ideal, but it’s a huge step in the right direction

Відповісти
Підтримати
sensei
Artem Maschenko CEO в PayJoy 20.09.2013 06:25

Я и не спорю что Java быстрее, просто привел пример реально работающего приложения — причем ребят из GameSpy. А тебе должно быть стыдно за сравнение «hello, world» и production приложения

Відповісти
Підтримати
reality_hacker
reality_hacker 20.09.2013 06:26
А тебе должно быть стыдно за сравнение «hello, world» и production приложения
Ну у них там тоже сферический конь в вакууме тестируется
Відповісти
Підтримати
Artem Maschenko
Artem Maschenko CEO в PayJoy 20.09.2013 06:28

ты вначале хоть статью прочитай, а потом говори

Відповісти
Підтримати
reality_hacker
reality_hacker 20.09.2013 06:30

Я прочел. А ты? Заметил какие-то детали что именно тестировалось? Какие? Подкинь конструктива, не набрасывай.

Відповісти
Підтримати
Artem Maschenko
Artem Maschenko CEO в PayJoy 20.09.2013 06:36

> Now on the Linux front, we used two equivalent quad-core, 2GB RAM XenServer VMs running CentOS5 to keep our tests as even as possible

Да и логически подумай, 200 ms с “hello, world” даже для рельсового приложения — много.

Відповісти
Підтримати
reality_hacker
reality_hacker 20.09.2013 06:39

Ну может быть у них конечно и более навороченная логика чем hello world, поэтому цифры без деталей абсолютно безсмысленны. С другой стороны по приведенной мной ссылке у руби задержки ниже 50мс не бывает, а у рельсов средняя 100мс, т.е. с учетом апгрейда железа с 2011-го года то на то и получается. www.techempower.com/...st=db&l=35s

Відповісти
Підтримати
Artem Maschenko
Artem Maschenko CEO в PayJoy 20.09.2013 06:51

Где ты там видишь Goliath? Ты сравниваешь палец с жопой. Да и вообще к чему эти сравнения? Java быстрее, но это не значит что на ruby нельзя написать быстрый сервер.

Твоя позиция — Java спасет мир, моя — язык не так важен. Каждый выбирает по потребностям и задачам. Тем более что микро-сервисы могут быть написаны на чем угодно.

Відповісти
Підтримати
reality_hacker
reality_hacker 20.09.2013 06:59
Где ты там видишь Goliath? Ты сравниваешь палец с жопой.
Лол, ты как бы сам рельсы упомянул
Java быстрее, но это не значит что на ruby нельзя написать быстрый сервер.
Достоверных подтверждений этого пока что не обнаружено. Хотя кому и в 30 раз медленнее — это быстрый и «holy crap».
моя — язык не так важен
Ну если хочется менеджить стадо серверов, ловить грабли и еще и платить за это денюжку, то конечно хозяин барин.
Відповісти
Підтримати
Artem Maschenko
Artem Maschenko CEO в PayJoy 20.09.2013 07:19
Лол, ты как бы сам рельсы упомянул
Ты читаешь между строк, я лишь сказал что 200 мс даже для рельсов это много
Достоверных подтверждений этого пока что не обнаружено. Хотя кому и в 30 раз медленнее — это быстрый и «holy crap»
Пример я тебе привел
Ну если хочется менеджить стадо серверов, ловить грабли и еще и платить за это денюжку, то конечно хозяин барин
Сервисов!!! Не серверов. Ты явно не в теме
Відповісти
Підтримати
reality_hacker
reality_hacker 20.09.2013 07:24
Ты читаешь между строк, я лишь сказал что 200 мс даже для рельсов это много
НУ а я тебе обьяснил что по тем временам для рельсов латентность 200мс была вполне Ок.
Пример я тебе привел
Торможной пример без деталей? Ок.
Сервисов!!! Не серверов. Ты явно не в теме
Та нет, все бенчмарки указывают на то что руби в 30 раз тормознее джавы, как вот здесь например: benchmarksgame.alioth.debian.org/...2=java&data=u32
Поэтому на больших нагрузках нужно минимум 30 руби серваков что бы заменить один джавовый.
Відповісти
Підтримати
Artem Maschenko
Mykola Kharechko developer в SoftServe 21.09.2013 12:47
Поэтому на больших нагрузках нужно минимум 30 руби серваков что бы заменить один джавовый.
неправда. більшість часу в реальності йде на i/o в серверних аплікаціях. тому цілком можливо що 1ява сервер == 1рубі сервер для якогось певного юзкейсу.
Відповісти
Підтримати
reality_hacker
Макс Матюхин программист в Badoo 21.09.2013 15:45
більшість часу в реальності йде на i/o в серверних аплікаціях.
Не верьте этой фразе пока сами в своём приложении не посчитаете.
Відповісти
Підтримати
Mykola Kharechko
reality_hacker 21.09.2013 18:23
неправда. більшість часу в реальності йде на i/o в серверних аплікаціях. тому цілком можливо що 1ява сервер == 1рубі сервер для якогось певного юзкейсу.
Это было во времена когда еще не придумали ССД, и базы не помещались целиком в памяти. Иначе как ты обьяснишь разницу в 30 раз в бенчмарках выше?
Відповісти
Підтримати
Mykola Kharechko
Mykola Kharechko developer в SoftServe 21.09.2013 22:49

між рам і кпу досі є велика різниця(викладачі в універі казали що завжди буде, при тому з аргументами). ну а ссд то ж смішно, ніби ж дорослі...(+згадай за мережу)
я не переглядав лінка з тестом і знову говорю що в ’певних юзкейсах 1явасервер==1рубісерер’. якщо на процесор велике навантаження то співвідношення буде в користь яви. і не 30 до 1, а значно менше

Відповісти
Підтримати
reality_hacker
reality_hacker 21.09.2013 22:50

За неимением аргументов традиционно идут набросы?

Відповісти
Підтримати
Mykola Kharechko
Mykola Kharechko developer в SoftServe 21.09.2013 22:56

думаю можна нагуглити швидкість ссд, рам і кпу.

Відповісти
Підтримати
reality_hacker
reality_hacker 21.09.2013 22:58

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

Відповісти
Підтримати
Mykola Kharechko
Mykola Kharechko developer в SoftServe 21.09.2013 23:00

в тому й справа що від буде тратити ту ж самі кількість що і явівський(плюс мінус кілька десятків тисяч котрі ні на що не впливають). сорі, але справді це смішно. інтепретатор чи компілятор всерівно буде робити системний виклик чи я десь помиляюсь?

Відповісти
Підтримати
reality_hacker
reality_hacker 21.09.2013 23:04
ратити ту ж самі кількість що і явівський
вызывающе неверное утверждение
нтепретатор чи компілятор всерівно буде робити системний виклик чи я десь помиляюсь?
будет, но они теряются по сравнению с работой по распаршиванию пакета от БД, представлении записи БД в виде динамически сконструированных обьектов, перекладыванию и генерированию данных в виде json или html. Бенчмарк выше это наглядно показывает.
Відповісти
Підтримати
Mykola Kharechko
Mykola Kharechko developer в SoftServe 21.09.2013 23:43

ріалті_хакер, ти несеш єресь. ті аргументи котрі я тобі навів вчать на 1-2гому курсі. якщо тобі справді цікаво як в динамічних мовах парситься json то йди в гугл по слово bindings(some_lang c extensions), а якщо просто дістати мене то йди певно нахєр.

Відповісти
Підтримати
reality_hacker
reality_hacker 21.09.2013 23:53
кщо тобі справді цікаво як в динамічних мовах парситься json
Тебе нужно с класса 1-го,2-го общеобразовательной школы начинать восполнять пробелы в образовании, так как читать ты умеешь плохо, я про парсинг json ничего не писал.

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

Відповісти
Підтримати
Mykola Kharechko
Mykola Kharechko developer в SoftServe 22.09.2013 00:26

на жаль моя система не підтримує ’perf stat -e cycles’ але завтра думаю найду де порівняти в інструкціях процесора ті речі про котрі ти говориш між сішкою і пітоном. в даний момент впевнений що пітонівський sys_write(’hello’) не значно повільніший сішного printf("hello"). завтра відпишусь.

Відповісти
Підтримати
reality_hacker
reality_hacker 22.09.2013 01:05

Мы же тут обсуждаем не хелловорлды, а нагруженные сервисы, в которых кроме helloworld есть еще куча логики, и вот бенчмарк на который я ссылаюсь вполне показывает статус кто есть кто: www.techempower.com/...st=db&l=1kw www.techempower.com/...est=db&l=3k

Відповісти
Підтримати
Mykola Kharechko
sensei 20.09.2013 06:25

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

Відповісти
Підтримати
Artem Maschenko
Artem Maschenko CEO в PayJoy 20.09.2013 06:32

В том то и дело что это production переписанный на новый сервер (уже старый, т.к. статья 2011го года) и прошедший все их тесты

Відповісти
Підтримати
sensei
Макс Матюхин программист в Badoo 19.09.2013 12:07

А чем всё это отличается от mongrel2 ? stackoverflow.com/...hy-use-mongrel2

Відповісти
Підтримати
Artem Maschenko
Artem Maschenko CEO в PayJoy 19.09.2013 16:56

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

Відповісти
Підтримати
Макс Матюхин
Artem Maschenko CEO в PayJoy 19.09.2013 19:00

Это просто messaging. Кстати говоря monglrel2 основан на нем

Відповісти
Підтримати
Beaver Green
Ivan Pomidorov 18.09.2013 23:08

Я бы покопал в строну решений, которые применяют в таких системах, — Hadoop, Oracle Coherence, Jboss Grid, да и обычный аппликейшон сервер с эджибями может масштабироваться так что будь здоров.

К примеру Grid Dynamics использует в своем безумно нагруженном е-коммерсе проекте оракл когеренс ( распредленный кеш ).

Плюс еще неплохо бы знать алгоритмы/структуры данных, вроде фильтра блума и т.п.

Відповісти
Підтримати
Valeriy Zamaraiev (junior lisper) 18.09.2013 14:14

Теория систем массового обслуживания (СМО). Напр, метро — офигенно высоконагруженная система. Читать про теорему Литла, распределение пуассона, можно посмотреть имитационное моделирование.

Ближе к нашим технологиям — телефонный PSTN свитч — тоже офигенная высоконагруженная система.

Если про сайтики — то вопрос не в кол. хитов в сек, а как это соотносится с capacity/utilization, плюс где какие очереди в системе (напр. в TCP стеке тоже есть очередь хотя бы на accept). Имхо исходники nginx’а читать нужно только чтобы под него потом пилить модули, не факт, что это нужно.

Затем — научиться все мерять / мониторить!

Еще пониже уровень — как работают инвет-лупы, select/epoll/kqueue — обязательно, libevent — это для упрощения жизни, но что там под капотом, надо понимать, ну, и, согласен про алгоритмы/структуры данных/понимание работы компьютера. Multithreading, конечно же и его эффект, в т.ч. context switching, кеши CPU и прочее. Тут надо предостеречь, что куча вещей настолько зависят от конкретного приложения, что общие рекомендации никогда не работают. Только мерять + опыт.

Сюда заглянуть www.kegel.com/c10k.html

Но очень часто все легче решать на более высоком уровне, т.о. то, что выше про СМО — это в любом случае может сэкономить кучу разработки.

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

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

Ах, да, чуть не забыл, в highload проектах как правило еще есть существенная операционная часть, много вопросов с деплойментами, как релизить новые версии, чтобы не сломать все и пр.
Как организовать саппорт сотен тыщ или миллионов пользователей и пр.

Відповісти
Підтримати
Valeriy Zamaraiev (junior lisper) 18.09.2013 18:46

И еще момент. Если хайлоад, то это же еще и вопрос денег, и часто немалых! А тут уже хотя бы надо понимать разницу CAPEX / OPEX. Тут подходим к вопросу о клаудах и вспомнил недавно прочитанную книжку. Тема не совсем техническая, но все, что касается клауда — это вопрос больше экономический. Клауд — это не только перекладывание капитальных затрат в операционные, там еще много чего интересного, Money Value of Time, например (as opposed to Time Value of Money).

Відповісти
Підтримати
Valeriy Zamaraiev
Bogdan Shyiak SE or Dev 18.09.2013 19:42
Теоретеги такие теоретеги
Практик, жги! (Если че, это не стеб, мне серьезно интересно ваше мнение)
Відповісти
Підтримати
reality_hacker
reality_hacker 18.09.2013 19:44

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

Відповісти
Підтримати
Bogdan Shyiak
Pavel Kruchina CTO 18.09.2013 19:53

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

Відповісти
Підтримати
reality_hacker
reality_hacker 18.09.2013 19:55

Вопрос был не в выучить, а почитать. Если есть какая то книжка описывающая базовые техники (load balancing, sharding/resharding) то ее стоит почитать новичку.

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 18.09.2013 20:10

Ну если почитать «без обязательств» то и указанное Valeriy Zamarayev пойдет.

Відповісти
Підтримати
reality_hacker
Pavel Kruchina CTO 18.09.2013 23:03

Если дифицита времени нет — то пофиг. + Многие компании редко когда обьясняют ПОЧЕМУ они выбрали ту или иную архитектуру — а для новичка это важно.

Відповісти
Підтримати
reality_hacker
reality_hacker 18.09.2013 23:33
Если дифицита времени нет — то пофиг.
Ты прав, можно и Толстого посоветовать почитать.
Многие компании редко когда обьясняют ПОЧЕМУ они выбрали ту или иную архитектуру — а для новичка это важно.
Зато из рассказов таких компаний видно какая архитектура и какие компоненты работают на практике. Ну и некоторые компании обьясняют почему.
Відповісти
Підтримати
Pavel Kruchina
Дмитрий Шемет iOS Dev 18.09.2013 20:22

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

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 18.09.2013 23:02

Язык то можно, но без понимания «когда надо» применять тот или инной подход — можно натворить бед.

Впрочем, джуном вас врядли пустят боевой сервер настраивать.

Відповісти
Підтримати
Дмитрий Шемет
Valeriy Zamaraiev (junior lisper) 18.09.2013 20:53

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

Відповісти
Підтримати
reality_hacker
reality_hacker 18.09.2013 21:23

Хайлоад спец, это который умеет делать и улучшать соответствующие системы. Вопросы бизнеса это уже другие люди, директора, VP, CEO/CTO/CFO и так далее. Сейчас определенные стеки уже вырисовались, и такому спецу нужно просто иметь его знания и практический опыт.

Відповісти
Підтримати
Valeriy Zamaraiev
Valeriy Zamaraiev (junior lisper) 19.09.2013 11:54

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

Відповісти
Підтримати
reality_hacker
reality_hacker 19.09.2013 18:22

Есть разница в стеке между просто джавой и high load джавой, например в high load джаве остро нужно кеширование, может быть nosql, data grid, логи писать собирать, парсить и упорядочивать нужно по другому, потому что их много, data modeling другой, на уровне алгоритмов внимательной смотреть на датаструктуры, и т.д.

Відповісти
Підтримати
Valeriy Zamaraiev
Valeriy Zamaraiev (junior lisper) 19.09.2013 18:47

Во первых — это ортогонально джаве вообще, замени джава на питон, например.

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

Відповісти
Підтримати
reality_hacker
reality_hacker 19.09.2013 18:50
Во первых — это ортогонально джаве вообще, замени джава на питон, например.
Разница думаю есть в выборе либ. Ну и какая разница ортогонально или нет?
А во вторых — все, что ты перечислил, нужно не в хайлоад вообще, а в конкретных задачах, и где что нужно, определяется путем измерений и рассуждений, основанных на понимании всех шагов обработки запросов, всех очередей в системе, загруженности конкретных ресурсов, вопросов надежности. да, а потом еще и денег тоже
Тогда и в программировании нету ничего что нужно «вообще», все нужно под конкретные задачи. Упраздняем собеседования, перечисление скилов в резюме и т.д.?
Відповісти
Підтримати
Valeriy Zamaraiev
Valeriy Zamaraiev (junior lisper) 19.09.2013 19:14

В программировании таки есть нечто «вообще», а именно алгоритмы/структуры данных, архитектура, включая все тобой перечисленные моменты. Просто человек, который умеет использовать все техники, тем не менее без понимания общей картины, основанной, повторюсь, на измерениях и понимании всего на уровне отдельных запросов, ресурсов их обрабатывающих, очередей, наваяет монструозную хрень, но зато все на новомодных технологиях.

И отдельная тема — это утечка абстракций, когда вдруг тебе надо крутить в ядре 100500 параметров, потому что значения по умолчанию хороши для какого-то «среднего» случая. И мир удобненьких фреймворков тоже начинает рушиться, потому что где-то вылезает какой-нибудь O(N^2), о котором на маленькой нагрузке никто и не догадывался.

Відповісти
Підтримати
reality_hacker
reality_hacker 19.09.2013 19:19
В программировании таки есть нечто «вообще», а именно алгоритмы/структуры данных, архитектура, включая все тобой перечисленные моменты
Ну вот в high load тоже есть общие темы, load balancing, анализ логов, и моделирование БД.
Просто человек, который умеет использовать все техники, тем не менее без понимания общей картины, основанной, повторюсь, на измерениях и понимании всего на уровне отдельных запросов, ресурсов их обрабатывающих, очередей, наваяет монструозную хрень, но зато все на новомодных технологиях.
Замечательно, я с этим полностью согласен.
И отдельная тема — это утечка абстракций, когда вдруг тебе надо крутить в ядре 100500 параметров, потому что значения по умолчанию хороши для какого-то «среднего» случая. И мир удобненьких фреймворков тоже начинает рушиться, потому что где-то вылезает какой-нибудь O(N^2), о котором на маленькой нагрузке никто и не догадывался.
практика показывает что с миром удобненьких фреймворков, зарекомендовавших себя и проверенных временем конечно, все Ок, по крайней мере в джава.
Відповісти
Підтримати
Valeriy Zamaraiev
Pavel Kruchina CTO 19.09.2013 08:59

Знать треть стека — это в каком виде? немножко о железе, немножко о алгоритмах, прочитал пару книг по бизнессу?

Відповісти
Підтримати
Valeriy Zamaraiev
Valeriy Zamaraiev (junior lisper) 19.09.2013 11:31

Я имел в виду скорее, глубоко знать несколько смежных областей, а не вразброс. Потому что на хайлоаде абстракции текут. Думаю, T-shaped skills тоже ок.

Відповісти
Підтримати
Pavel Kruchina
idOne Арбузный 21.09.2013 12:51

Не стоит быть таким самокритичным.

Відповісти
Підтримати
reality_hacker
Макс Матюхин программист в Badoo 17.09.2013 01:09
Сидеть долго дома и что-то писать своё не хочу, так как реальный опыт то не там
врятле вас возьмут в проект с высокими нагрузками, если у вас нет хотя бы знаний (не говоря уже про опыт). Поэтому читать всё про высокие нагрузки и масштабирование и пробовать самому что писать — для вас один из вариантов.

Высокие нагрузки — очень расплывчатое понятие и в разных конторах эту проблему решают по разному и разными инструментами. Если вам нравится С и если знаете линукс, то один из возможных вариантов — написание каких-нибудь быстрых сервисов (демонов) на С. Посмотрите исходники nginx, memcached, redis, почитайте про libevent / libev. Попробуйте написать модуль для nginx. Ну и конечно — алгоритмы, структуры данных и понимание как работает компьютер
Не знаю, возьмут ли вас в работу компании работающие с большими нагрузками, но на собеседовании будет чувствовать себя увереннее :)

И я по правда не в теме, нужны ли такие спецы в украине

Відповісти
Підтримати
Дмитрий Шемет iOS Dev 17.09.2013 09:40

Да я понимаю, что сразу синьором не пойду туда :)
с нуля начинать, да.
Думаю, нужны (хочется надеяться)

Відповісти
Підтримати
Макс Матюхин
Нестор Иванович 17.09.2013 01:06

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

Відповісти
Підтримати
Нестор Иванович 19.09.2013 01:42

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

Відповісти
Підтримати
Дмитрий Шемет
Seven Berg 16.09.2013 20:48

Подскажите пожалуйста стоящую книгу.

Відповісти
Підтримати
Макс Матюхин программист в Badoo 17.09.2013 01:32

книг не знаю, но есть в России конференция — highload, позиционирует себя как конференция по высоким нагрузкам. Можно поискать в сети видео докладов. Там конечно не стоит всё воспринимать на веру, но для новичка многие вещи будут интересны.
Какие то из докладов они выложили здесь — profyclub.ru/docs

Відповісти
Підтримати
Seven Berg
Олексій Пєніє 16.09.2013 17:33

Высоконагруженные системы — это высокоРАЗгруженные системы. То есть какое-то место [и в разных проектах — разное] становится узким местом и начинает требовать СКОРОСТЬ или НАДЁЖНОСТЬ.

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

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

Высоконагруженные системы имеют достаточно сильное разделение труда. Потому наверняка будет отдельный специалист который рулит нагрузкой и резервированием. Именно он будет отвечать за показатели, и под его руководством (!!!) программисты будут делать. Не учить, а именно learning by doing.

Ивенты по высоконагруженным системам — это всё равно что конкрус красоты в скафандрах: все говорят, но тема сисек не раскрыта.

Ключевые знания — теория информации. Учат в ВУЗе. Добывается в виде книги элементарно.

Відповісти
Підтримати
devv 18.09.2013 22:21
Высоконагруженные системы — это высокоРАЗгруженные системы
Что бы это значило?
Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 19.09.2013 05:50

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

Но чаще всего начинаестя разгрузка не с этого. А с изучения узкого места, выявления характера затыка скорости: DDoS; пиковая нагрузка в пределах нормального мат.ожидания человеком, или превышающая; создаёт ли её линейный софт или админы лезут кривыми ручками; итд, итп.

Узкое место становится объектом системы управления качества. Читай канбаном. Этот канбан получает своё цикл качества, и заканчивается выходом к требуемым показателем и переходом в медленный цикл (назначается аналитика).

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

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

Відповісти
Підтримати
devv
reality_hacker 19.09.2013 07:04

А как на счет перегрузки и недогрузки? Каково их приминение по вашему мнению?

Відповісти
Підтримати
Олексій Пєніє
Alex Batler заговорщик в Mutabor-science 19.09.2013 11:10

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

Відповісти
Підтримати
reality_hacker
amigo 19.09.2013 12:47
по вашему мнению?
Оффтоп. Это первый раз на этом форуме вы обращаетесь к другому человеку на вы?
Відповісти
Підтримати
reality_hacker
Nobody 19.09.2013 12:59

Так ведь именно Хацкер уже высказывал сомнение в гуманоидной природе этого аккаунта.
dou.ua/...ic/7754/#335941
А тут ещё Ноунейм со своим Куршавелем-предсказателем.
Так что лучше быть повежливей, а вдруг он и правда того... фоглетовый... Дезавуирует, и всхлипнуть не успеешь.

Відповісти
Підтримати
amigo
reality_hacker 19.09.2013 18:17

Еще были Антон Ляшенко и Максим Федоренко.

Відповісти
Підтримати
amigo
sensei 20.09.2013 02:13
Антон Ляшенко
а говоришь у нас гуглов не делают
Відповісти
Підтримати
reality_hacker
reality_hacker 20.09.2013 02:21

У него просто фронтенд к гуглу. Толи дело shukalka.com.ua

Відповісти
Підтримати
sensei
sensei 20.09.2013 02:28

шукалка не шукаэ

У него просто фронтенд к гуглу
та не, наоборт, то гугл коннектится к нему
и вообще гугл апи разработали с прицелом на в-сёрч
Відповісти
Підтримати
reality_hacker
Alex Batler заговорщик в Mutabor-science 20.09.2013 14:58

Не просто фронтенд, а фронтендец.
Щас вот зашел, покликал... Получил такое:
«Доступ на сайт закрыт
По причине нарушения правил сайта вам был закрыт доступ.
»
Удивился, что сообщение таки на правильном русском языке. Теряется неповторимый стиль...

Відповісти
Підтримати
reality_hacker
Ivan Pomidorov 18.09.2013 23:03
теория информации
Кукаретик ты, как знание теоремы шенона-найтвиста или всякого кодирования непосредственно поможет тебе писать хайлоад веб/телеком проекты? Вот для пацанов которые всякие архиваторы пишут пригодиться.
Відповісти
Підтримати
Олексій Пєніє
Вера Кузнецова 19.09.2013 01:28

Видно, что жава-мид вышел на арену :)
Чем тебе Найквист то не угодил?

Відповісти
Підтримати
Ivan Pomidorov
Ivan Pomidorov 19.09.2013 12:11

Та просто теория информации это больная тема у меня.

Відповісти
Підтримати
Вера Кузнецова
Олексій Пєніє 19.09.2013 06:54

А кто сказал что прям ВСЁ пригодится. Я же не сказал «зубрить», я сказал «скачать». Прочитал по диагонали — и знаешь где чего. Или ты думаешь я знаю теорему :)

Но вот когда дело упрётся в расчёт избыточности — что будешь делать? Кричать «даёшь много-много быстро-быстрого железа»?
Когда тебя накроет каким-нить хабраэффектом — будешь требовать удесятерить ресурсы?
Когда тебе придётся кешировать данные — будешь хватать всё подряд? Или воспользуешься LRU-стратегией? Или таки с вероятностью подружишься.
Когда одно звено окажется ненадёжным — завалишь всю систему или подумаешь о резервировании?
Когда звено вне зоны твоего контроля и оно необходимо — придумаешь 100500 отмазок, или таки разберёшься как ему сделать серверную обёртку?
Когда понадобится работать в условиях ненадёжной связи (мобайл) — будешь жечь трафик или таки научишься иметь поддержку hi-load на стороне клиента?

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

Відповісти
Підтримати
Ivan Pomidorov
Ivan Pomidorov 19.09.2013 12:17

Вот только это все делают и без знаний в теории информации, ну кроме

Когда понадобится работать в условиях ненадёжной связи (мобайл) — будешь жечь трафик или таки научишься иметь поддержку hi-load на стороне клиента?
Відповісти
Підтримати
Олексій Пєніє
Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 16.09.2013 14:17

Почитайте для расширения кругозора — highscalability.com.
Мой совет: GPU не занимайтесь, оно пока не выстрелило.
Не найдете работы в Украине, не найдете проектов.

Відповісти
Підтримати
Дмитрий Шемет iOS Dev 16.09.2013 15:16

О, это тот комментарий, которые мне был нужен.
Тогда полезу смотреть серверную часть только:)
А как насчёт языков? Мне хочется что-то а-ля Go потыкать, а то джава не возбуждает :)

Відповісти
Підтримати
Ivan Golovach
Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 16.09.2013 16:42

По языкам — я не в курсах. Советовать как все Go/Erlang/ ... не буду.
Сам пишу на яве. Все норма. На ней много всего облачного написано.
Меня больше интересуют распределенные системы, все таки там главное не битва за наносекунды и биты, а всякого рода CAP-теорема, векторное/матричное время и прочее. И там gc, встроенная многопоточность и прочее — доставляют.
Попробуйте посмотреть на такую тулзу — Zookeeper. Это аналог гугловского Chubby lock service, только на яве и от Yahoo. Авторы утверждают, что Zookeeper — это, в том числе, конструктор распределенных структур данных.

Відповісти
Підтримати
Дмитрий Шемет
Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 16.09.2013 16:44
Мне хочется что-то а-ля Go потыкать
У actor-based языков есть свои проблемы. Скажем не понятно как работать с большим состоянием. Скажем кэш на 10М сущностей. Это один актор, или 10М?
Відповісти
Підтримати
Дмитрий Шемет
reality_hacker 16.09.2013 22:56
У actor-based языков есть свои проблемы. Скажем не понятно как работать с большим состоянием. Скажем кэш на 10М сущностей. Это один актор, или 10М?
Ты чета попутал, в го совсем не актеры
Відповісти
Підтримати
Ivan Golovach
Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 17.09.2013 00:40

Да, действительно попутал.
1) goroutine, а не actor
2) Go memory model допускает прямой шаринг данных и data race
3) каналы независимы от горутины (не привязанные mailboxes) и, похоже, нельзя послать данные горутине по имени (так как нет привязанного mailbox)
.
Память подвела. Спутал посыл сообщения в mailbox и по channel.

Відповісти
Підтримати
reality_hacker
Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 17.09.2013 01:08
1) goroutine, а не actor
Хотя вот это выглядит как актор — 

go func() {
    for {
        select {
            case <-ticker.C:
                logState(urlStatus)
            case s := <-updates:
                urlStatus[s.url] = s.status
        }
    }
}()
</a>
Відповісти
Підтримати
Ivan Golovach
Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 16.09.2013 23:22
О, это тот комментарий, которые мне был нужен.
Я бы не особо доверял мнению профанов в этом вопросе.
Відповісти
Підтримати
Дмитрий Шемет
Дмитрий Шемет iOS Dev 17.09.2013 09:32

Ну давайте без перехода на личности :)
Лучше опишите свою позицию — всем только лучше будет (мне так точно)

Відповісти
Підтримати
Mike Gorchak
Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 17.09.2013 09:42
Ну давайте без перехода на личности :)
Какие же тут личности, это констатация факта.
Лучше опишите свою позицию — всем только лучше будет (мне так точно)
Моя позиция — прислушаться к совету ScorpZ с небольшой ремаркой, либо вначале разобраться с CUDA и потом обязательно разобраться с OpenCL, либо наоборот, вначале с OpenCL, потом с CUDA. Как я уже говорил ниже спрос есть и на OpenCL даже выше, чем на CUDA (не будем спорить что продуктивней и при каких условиях), попробруйте на линкедине добавить, что вы знаете OpenCL и CUDA и будет результат.
Відповісти
Підтримати
Дмитрий Шемет
Дмитрий Шемет iOS Dev 17.09.2013 10:04

Спасибо
Если честно, то меня больше OpenCL/CUDA/Deamons привлекают, нежели серваки.

Покопаю на днях.

Відповісти
Підтримати
Mike Gorchak
Golden Boy 18.09.2013 12:05

А с чего вы взяли, что Иван Головач профан? Я работал с ним в двух разных компаниях в разное время. Оба раза на проектах которые без зазрения совести можно назвать высоконагруженными (миллионы реальных посететелей). И оба раза он делал на них важные и ключевые вещи (Один раз тюнил очень жесто перформанс, второй — разрабатывал собственный протокол сериализации). Кроме этого, я точно знаю, что он разработал ещё как минимум один высоконагруженный и распределённый gaming сервис.

Відповісти
Підтримати
Mike Gorchak
Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 18.09.2013 16:47
А с чего вы взяли, что Иван Головач профан?
После вот это фразы.
Мой совет: GPU не занимайтесь, оно пока не выстрелило.
Сумашедший рынок, существует более 5 лет, много вакансий по миру и немного в Украине в частности, десятки тысяч проектов и всё это одной фразой похерил Ваня Головач.
Відповісти
Підтримати
Golden Boy
Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 18.09.2013 17:40

Ну так приведите же эти вакансии!
Где они, эти сотни тысяч предложений о работе.

Відповісти
Підтримати
Mike Gorchak
Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 18.09.2013 18:11
Ну так приведите же эти вакансии!
bit.ly/18ykvnV
Где они, эти сотни тысяч предложений о работе.
Я даже боюсь спрашивать откуда взялась цифра в 100000?
Відповісти
Підтримати
Ivan Golovach
Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 18.09.2013 20:28

Правильно ли я Вас понимаю, что Вы не можете привести множество вакансий на CUDA/GPU? Вы предлагаете мне самому используя google доказывать что я профан? Трюк хорош, но пока Ваше утверждение остается бездоказательным.

Відповісти
Підтримати
Mike Gorchak
Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 18.09.2013 20:51

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

Відповісти
Підтримати
Ivan Golovach
Вера Кузнецова 19.09.2013 01:32

Хи-хи. Ты глянь на тайтл Майка. У него в теме Куды и ОпенЦЛ черный пояс :)

Відповісти
Підтримати
Ivan Golovach
ScorpZ Lapshov C++/C# && other programmer в AMC Bridge 16.09.2013 23:19

На счет вычислений на GPU, это CUDA называется (ну не только CUDA, но это сейчас мэйнстрим). А вот, что не выстрелило, это не правда, очень даже и выстрелило, просто в Украине это нафик никому не надо.

Відповісти
Підтримати
Ivan Golovach
Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 16.09.2013 23:24

В Украине пару лет назад интенсивно бегали вакансии для OpenCL, может и сейчас есть.

Відповісти
Підтримати
ScorpZ Lapshov
Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 17.09.2013 00:42
А вот, что не выстрелило, это не правда, очень даже и выстрелило
Я не имел в виду бесполезно или не работает, я имел в виду, возможно, не стоит в нашей стране стартовать с этого. Так как тяжело будет найти работу, материалы, помощь от других. Возможно, при старте, стоит выбрать что-то более популярное, что бы не попасть в вакуум.
Відповісти
Підтримати
ScorpZ Lapshov
Pavel Kruchina CTO 16.09.2013 12:37
Высоконагруженные системы — с чего начать?
С работы в компании, где есть эти самые высоконагруженные системы.
Відповісти
Підтримати
Дмитрий Шемет iOS Dev 16.09.2013 12:38

Это крутой ответ, но я как раз хотел узнать, есть у нас тут кто где:)

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 16.09.2013 12:41

берёте сайт типа work.ua или того же доу, находите продуктовые компании, пилящие популярные продукты, и засылаете туда свое резюме.

Відповісти
Підтримати
Дмитрий Шемет
Вера Кузнецова 19.09.2013 01:35

Пойдите в КС или МТС. Сделайте наконец так, чтобы биллинг контрактников просчитывал за пару часов :)

Відповісти
Підтримати
Дмитрий Шемет
Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 16.09.2013 12:18
высоконагруженные системы, всякие параллельные вычисления
Это «две большие разницы».
Типичная высоконагруженная система для старта:
— свой облегченный чат-сервер на WebSockets (10К-50К соединений)
— свой DNS-сервер (10К запросов в секунду)
— свой сервер для раздачи потокового видео
— свой HTTP- или SOCKS-прокси сервер.
— свой простейший In Memory Cache на 1G-10G данных для 10К запросов в сек по сети.
Для первой пробы выбираете подмножество протокола (2-5 комманд), качаете чужую реализацию из инета и перепиливаете для нагрузки.
Відповісти
Підтримати
Дмитрий Шемет iOS Dev 16.09.2013 12:39

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

Відповісти
Підтримати
Ivan Golovach
Volodymyr Bryliant Self-employed developer 18.09.2013 21:45

Для вебсокетів можна взяти socket.io, знайти і поправити вузькі місця. Далі або закинути запит змін в головну гілку socket.io, або зробити платне швидкодійне відгалуження. Замість socket.io можна підставити будь-яку розвинену популярну технологію. На будь-якій популярній технології ви самі зможете заробляти колосальні гроші, головне не розгалужуватись і не пришвидшувати зразу дві технології.

Відповісти
Підтримати
Ivan Golovach

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.