Подскажите с языком сценариев для AI

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

Добрый день.
Разрабатываю ядро технологического стартапа в области online betting. Сейчас реализую нагрузочное тестирование. Необходимо задавать различные сценарии поведения внешними «нагрузочными роботами».
.
1. 4 группы сценариев: аноним (заходит, смотрит), пользователь (делает ставки, вводит/выводит деньги, подписывается на турниры, общается во внутреннем чате), админ (создает турниры, блокирует пользователей), футбол (генерирует события футбольного матча).
2. Декларативный/аппликативный стиль программирования — широкие возможности построения комбинированного стиля поведения из 2-х других. То есть если мы задали, скажем, пару стилей поведения пользователя — «нервный» и «непредсказуемый» (это не синонимы или антонимы, а «имена» двух конкретных экземпляров сценариев поведения), то мы имеет широкий спектр возможностей комбинирования этих стилей. Условно говоря, из двух экземпляров мы можем построить — ребенка этой пары, коллектив из двух друзей с такими характерами, психопата с совмещением двух личностей и т.д. просто передав сценарии различным операторам объединения.
3. На «пространстве сценариев» будет организован направленный поиск сценариев максимально доставляющих сложности серверу под нагрузкой.
4. Сценарии коллективного поведения (паника, истерия, атака троллей, атака betting-роботов ...) - приветствуются. Как никак пора готовиться к ЕВРО 2016.
5. Да, рабочий режим сервера 100.000 одновременных пользователей (анонимные наблюдатели + зарегистрированные игроки) = REST + WebSocket.
---
К слову, ищем (можно remote, сами мы в Харькове):
1. Админа/DevOps накрутить кластер из Linux-ов на 100.000 открытых TCP-соединений (WebSocket + SockJS + STOMP).
2. JVM-программистов (Java 8, Scala, Clojure) понимающих, что такое Netty, persistent data structures, java.util.concurrent, non-blocking data structures, Cassandra, Spring (REST, WebSockets, AOP).
3. ReactJS программистов на front end.
3. Платим — хорошо и сейчас. Дальше — больше. Финансируемся «Госдепом».
---
Товарищи и гражданочки, не надо писать сайты в Амазоне, пишите реальные высоконагруженные проекты в Украине:)

Теми: AI

// matches /foo/ path("foo" /) // matches e.g. /foo/123 and extracts "123" as a String path("foo" / """\d+""".r) // matches e.g. /foo/bar123 and extracts "123" as a String path("foo" / """bar(\d+)""".r) // similar to `path(Segments)` path(Segment.repeat(10, separator = Slash)) // matches e.g. /i42 or /hCAFE and extracts an Int path("i" ~ IntNumber | "h" ~ HexIntNumber) // identical to path("foo" ~ (PathEnd | Slash)) path("foo" ~ Slash.?) // matches /red or /green or /blue and extracts 1, 2 or 3 respectively path(Map("red" -> 1, "green" -> 2, "blue" -> 3)) // matches anything starting with "/foo" except for /foobar pathPrefix("foo" ~ !"bar")

| is the alternation combinator. It says “succeed if either the left or right operand parse successfully” ~ is the sequential combinator. It says “succeed if the left operand parses successfully, and then the right parses successfully on the remaining input” ~> says “succeed if the left operand parses successfully followed by the right, but do not include the left content in the result” <~ is the reverse, “succeed if the left operand is parsed successfully followed by the right, but do not include the right content in the result” ^^=> is the transformation combinator. It says “if the left operand parses successfully, transform the result using the function on the right” rep => simply says “expect N-many repetitions of parser X” where X is the parser passed as an argument to rep

Ctrl + Enter

anonymous 10.05.2017 12:17

Александр Берковский Java Developer – EPAM Systems 04.02.2016 23:25

Иван и все же возвращаясь к вопросам про обучения на Scala ??? все таки реально не красиво взять за курс 400 доларов и пропасть

Відповісти

Підтримати

Max Bondar Software developer в freelance 25.01.2016 19:43

Иван Вы еще с

online betting

работает ?

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 26.01.2016 18:51

Да, online betting в играх + всякого рода DSP / SSP / TDS — это рынки онлайн рекламы.

Max Bondar

Max Bondar Software developer в freelance 26.01.2016 21:04

Вам сотрудники еще нужны ? у меня есть опыn работы в

betting company

Ivan Golovach

Slava Boichenko Full Stack Engineer в Elementum SCM 16.11.2015 20:27

Иван, добрый день. А вы не хотели бы вернуться в групповой чат Skype и объясниться с ребятами, с которых взяли деньги за курс по Scala и пропали? Как-то это не очень красиво с Вашей стороны

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 16.11.2015 21:25

Ответил.

Slava Boichenko

Slava Boichenko Full Stack Engineer в Elementum SCM 16.11.2015 22:56

Ответили, но никакой конкретики. Если возвращаете деньги — напишите когда и как. Я лично устал уже писать вам, вашей жене, в чат и не получать никакого ответа

Нестор Иванович 18.11.2015 00:48

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

Slava Boichenko Full Stack Engineer в Elementum SCM 17.06.2016 20:52

Вот тут dou.ua/forums/topic/17746

Нестор Иванович

Slava Boichenko Full Stack Engineer в Elementum SCM 04.02.2016 20:47

Иван, вы собираетесь выполнять свои обещания? В противном случае мы с группом предпримем следующие шаги

Dmytro Volkov 16.11.2015 19:06

Вам нужен Drools

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 16.11.2015 19:16

Drools — это система описания и следования бизнес-правилам.
А мне нужна система в которой большое количество операторов соединения поведений в новое поведение.

Dmytro Volkov

Dmytro Volkov 16.11.2015 20:25

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

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

Зачем-то вы предположили что для реализации такого нагрузочного тестирования вам нужен оператор объединения сценариев. Вы уверенны что вам это нужно и это приблизит вас к решению основной задачи?

Если действительно нужно, то сценарии на Drools описывают правила поведения пользователя, и нагрузочные действия будут совершаться на основании интерпретации правил, а другая программа реализует операцию сложения сценариев. Соответственно правила должны быть написаны таким образом чтобы поддерживать относительно легкое объединение. Генератор сценариев будет использовать начальные созданные сценарии и оператор объединения для создания большого количества похожих но других сценариев. То есть успешность этой процедуры (то есть того что сценарии будут показательными и близкими к реальности), зависит не столько от оператора сложения, сколько от правильности начальных сценариев, которые создавались вручную. Соответственно, если показательность сценариев зависит от того как сценарии были созданные вручную, то может и не стоит генерировать эти тысячи сценариев, а просто создать нужные сценарии вручную?

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

Если же не ставить задачу узнать как ведет себя сервер на типичных сценариях, а ставить задачу найти сценарии, которые будут доставлять серверу наибольше проблем, то я не вижу в этом смысла. Ну, предположим, что таким перебором вы нашли сценарий, который больше всего нагружает сервер, но этот сценарий очень далек от типичного поведения пользователей (например, заходить в настройки, изменять там одно поле, потом в чат, потом опять в настройки, опять менять это же поле, опять в чат, опять в настройки, и так 100 раз). Что вы будете делать с этой информацией? Да, такой сценарий больше всего грузит, и что? Ведь вероятность того что пользователь так себя поведет возможно ничтожно мала, и в решение этой «проблемы» не имеет смысл вкладывать ресурсы.
А вот если протестировать типичные сценарии поведения пользователя, и при каком-то из этих сценариев будет сильная нагрузка, то это проблема которую надо решать. Только для такого тестирования не нужен оператор объединения сценариев, нужно просто вручную написать эти сценарии изначально.

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 16.11.2015 20:59

Нагрузочное тестирование на типичных сценариях — это самый базовый вариант.
Мне интересен поиск уязвимостей в реализации сервера. Скажем, какое-то действие (изменение настроек инвалидирует очень дорогой в построении кэш). Или уход из чата — сбрасывает какой-то кэш. Тогда найденный сценарий чат-настройки-чат-настройки, который работает в 100 раз хуже, чем просто чат или просто настройки покажет мне, где я дал маху.
.
У нас тут множество высокоуровневых фреймворков (например — Linux + java.io/NIO/NIO.2 + Tomcat impl + Spring WebSockets + SockJS + STOMP — это все cтек WebSockets) и все это добро работает auto-magically. И вот надо посмотреть где оно может «давать течь».
.
Ну или не инвалидируется дорогой кэш, а наоборот — переполняется на шизоидных сценариях.
.
У нас «самый жир» по деньгам ожидается на турнирах во время футбольных матчей ЕВРО 2016. И тут если ты посыпался в финале, то все, матч прошел и жди 4 года.

Dmytro Volkov 16.11.2015 21:10

Скажем, какое-то действие (изменение настроек инвалидирует очень дорогой в построении кэш). Или уход из чата — сбрасывает какой-то кэш. Тогда найденный сценарий чат-настройки-чат-настройки, который работает в 100 раз хуже, чем просто чат или просто настройки покажет мне, где я дал маху.

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

Нагрузочное тестирования, и поиск неоптимальных кусков кода, и поиск хитрых багов, в коммерческих проектах делают обычно на типичных сценариях, а не на всех возможных сценариях. У вас ведь не Life Critical система?

1. Я хочу знать про эти места и самостоятельно оценить — должен ли в этих местах тормозить сервер или нет.
.

У вас ведь не Life Critical система?

Что под этим имеется в виду? Никто конкретно не умрет.
Но высоконагруженные проекты так не делают.
Что мне говорить заказчику — «ну ... может сервер и упадет во время Чемпионата Мира ... ну никто же не умрет, в конце концов?».

Нестор Иванович 16.11.2015 11:34

gatling.io — недавно пробовал на своем проекте
жирный плюс — написан на akka +netty а сценарии — тупо scala код
простые кейсы можно будет вообще рекордером записать
в общем очень советую

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 16.11.2015 13:49

А как он в сравнении с Tsung
tsung.erlang-projects.org
по фичам?
.
Понятно, что JVM-программистам проще жить со Scala, а не Erlang кодом.

Ruslan Shevchenko Researcher 16.11.2015 19:16

ну главное отличие — в gatling модель теста пишешь на scala, а в tsung — XML-ем (который ограничен) [warn: это знание возможгно устарело]. В остальном — приблизительно похоже

Нестор Иванович 16.11.2015 22:11

Tsung не пробовал

anonymous 16.11.2015 00:37

Купите себе App dynamics или New Relic и успокойтесь. На крайний случай — jmeter. Кроме того, это тесты делаются после выхода в продакшен, а не до.

Нестор Иванович 16.11.2015 11:46

отличный совет
Вот благодаря таким подходам я один проект уже скоро год напильником в рамки приличий загоняю — уже с AppDynamic, JProfiler, JMeter, Gtling.io и всей королевской ратью. К счастью началось это за долго до выхода в продакшен и результаты ок

anonymous

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 15.11.2015 18:11

Интересно, скажем, используются ли где-то возможности Scala для создания Internal DSL с целью порождения широкого класса “операторов соединения”.
Как в Spray/Akka-http (Magnet pattern):
doc.akka.io/...2/scala/http/routing.html

val route =
  a {
    b {
      c {
        ... // route 1
      } ~
      d {
        ... // route 2
      } ~
      ... // route 3
    } ~
    e {
      ... // route 4
    }
  }

.
doc.akka.io/...a/http/path-matchers.html

.
2. Или классические Pattern Combinators
вот часть операторов = bitwalker.org/...scala-parser-combinators

Ruslan Shevchenko Researcher 14.11.2015 21:16

Ну тут скорее тулза, чем язык. Gattling gatling.io/ позволяет подобные сценарии на scala писать

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 14.11.2015 21:46

1. Есть поддержка WebSockets — gatling.io/...2.1.7/http/websocket.html
2. Последовательная композиция сценариев
val scn = scenario("Scenario Name").exec(Search.search, Browse.browse, Edit.edit)
---
Думаю, может подойти, спасибо.
---
Интересно, существуют ли более общие модели поведения, чем просто последовательности шагов с ветвлениями? Скажем, можно ли в каких-то моделях указать «ярость», «нетерпеливость», «непоследовательность» и образовывать их композиции? В моей задаче это уже over-engineering, но интересно, скажем в контексте композиции AI-компонент робота (распознаватель ситуации детектировал в окружающей ситуации «тревожность» и «неопределенность» и это передалось на поведение ходовой части (как у Big Dog от Boston Dynamics)). Учитывая темпы в этой области
— распознавание выражений лиц = www.inverse.com/...ogy-to-guess-your-emotion
— постройка 3D-модели окружения по видео
— ходящие роботы = www.youtube.com/watch?v=W1czBcnX1Ww
скоро это все добро будет необходимо интегрировать в рамках каких-то общих моделей/языков поведения.

Ruslan Shevchenko

Ruslan Shevchenko Researcher 15.11.2015 08:03

время длительности этих шагов / частоты событий для которых есть реакции ?

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 15.11.2015 18:00

Один пользователь генерирует событие (ставка, сообщение в чат) раз в 10-100 секунд. Одному пользователю приходят различные события по WebSocket (сообщение в чат, ваша ставка сыграла, событие в матче, обновление турнирной таблицы) — раз в секунду.
.
Пользователей непосредственно сейчас в тестировании 10к, через 3-6 месяцев — 100к.
.
Однако некоторые ситуации могут провоцировать пользователей на «неравномерное поведение»:
— что-то увидели по видео-трансляции матча и ринулись делать ставки
— сговорились в чате ставить на какое-то определенное событие в определенное время («мужики, точно говорю — будет гол!»)
— событие в матче привело к массовому выигрышу/проигрышу (все ставили на гол и он был), что спровоцировало массовую ответную реакцию

anonymous 16.11.2015 00:38

через 3-6 месяцев — 100к

100к это вообще не нагрузка. Пара инстансов jetty выдержит без особого проседания latency.

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 16.11.2015 13:52

100.000 открытых WebSockets в пиковой производительностью 100.000 сообщений в секунду?
тут проблема в бизнес-логике, что бы она не посыпалась
.
Jetty, Netty, ... то выдержат

anonymous 16.11.2015 14:08

100.000 открытых WebSockets в пиковой производительностью 100.000 сообщений в секунду?

Ничего волшебного. Боттлнека в IO тут не будет. А вот если каждый раз писать в БД то время отклика просядет, можете не сомневаться.
Здесь зависит от того насколько критично время отлика, если это live-ставки, то лучше их процессинг вынести на отдельный сервер где это будет процесситься отдельным пулом тредов.
Вам подойдет LMAX-подобная архитектура для сервиса live ставок.
martinfowler.com/articles/lmax.html

Ruslan Shevchenko Researcher 16.11.2015 19:26

Я бы генерировал feed событий привязанных ко времени, а скрипты симуляции эти feed-еры бы использовали. gatling.io/...2.0.1/session/feeder.html )

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 16.11.2015 21:02

Это похоже на то, что нужно.

Владимир Кожаев 14.11.2015 20:35

Почему бы в качестве языка сценариев не использовать? ДРАКОН

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 14.11.2015 21:30

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

Владимир Кожаев

Владимир Кожаев 14.11.2015 23:43

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

Если тебе интересно, пиши в личку — расскажу подробнее

Ivan Golovach Scala/Java TechLead в Moebius Lab (Real-Time Bidding) 15.11.2015 18:01

Отдельные сценарии я неплохо воспринимаю и текстом на языке программирования.
Интересна возможность комбинирования сценариев.

Владимир Кожаев 15.11.2015 19:14

Что значит «комбинировать» в данном контексте?

Выше объяснял.

Нестор Иванович 16.11.2015 11:35

держите наркомана!

Подскажите с языком сценариев для AI

39 коментарів

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