Подскажите с языком сценариев для 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. Платим — хорошо и сейчас. Дальше — больше. Финансируемся «Госдепом».
---
Товарищи и гражданочки, не надо писать сайты в Амазоне, пишите реальные высоконагруженные проекты в Украине:)

👍ПодобаєтьсяСподобалось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

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

Иван Вы еще с

online betting
работает ?

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

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

betting company

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

Ответил.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интересно, скажем, используются ли где-то возможности 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
// 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")
.
2. Или классические Pattern Combinators
вот часть операторов = bitwalker.org/...scala-parser-combinators
| 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

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

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
скоро это все добро будет необходимо интегрировать в рамках каких-то общих моделей/языков поведения.

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

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

через 3-6 месяцев — 100к
100к это вообще не нагрузка. Пара инстансов jetty выдержит без особого проседания latency.

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

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

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

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

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

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

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

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

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

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

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

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